WJX OpenAPI CLI

The problem it solves

WJX operations are split across a web console: creating surveys, editing question types, changing publish status, submitting test responses, pulling results, and managing contacts or subaccounts usually requires manual clicks or URL assembly. For AI agents or automation scripts, the hard part is not calling the API, but translating a natural-language request into a valid survey structure and extracting the right identifiers from responses, such as vid, sid, pagination totals, and verified fill-in paths, without treating backend IDs as public URLs or presenting one page of answers as the full dataset.

Core behavior

The skill wraps the WJX OpenAPI CLI and organizes business actions into explicit subcommands:
- Survey creation: prefer wjx survey create-by-json with JSONL templates, using jsonl-template before submission to avoid legacy fields such as q_type and items.
- Responses: cover response query, response submit, response report, and response download, with validation from submit-template and per-submission verification for batch jobs.
- Listing and links: use survey list to read pagination totals and short-path fields, while keeping fill-in URLs, edit URLs, and creation URLs separate.
- Operations and analytics: support contacts, departments, admins, subaccounts, tags, and local analytics such as NPS, CSAT, and anomaly detection.

Boundaries and cautions

It is useful when survey creation, test submission, result export, or contact management should be delegated to an AI. Note that missing or expired API Keys block authenticated actions; NPS, matrix, and exam questions have fixed JSONL fields; the survey --type is not the same as question type; and list or response queries must be completed by checking total_count, page_index, and page_size, rather than relying on table output instead of JSON parsing.