Ticket Fairy
Ticket Fairy CLI
ticketfairy manages events, tickets and orders, reads
customer and Vault data, and exports orders and customers from the command line, a scheduled job or an AI
assistant. You can script the event operations you repeat in the dashboard.
Install it in one command, sign in with the account you already have, and start with
ticketfairy event list.
Free with your Ticket Fairy account. MIT licensed. Requires Node 20 or newer.
Use the dashboard for a one-off change. Use the CLI when you need the same setup across several events, a report on a schedule, or an action another system starts.
Clone a previous event, create events and ticket types from JSON or YAML files, or send invitations from a CSV list. Event and ticket-type create and update commands accept --from-file, and invitations accept --from-csv. Keep the source file and run it again when you need it.
Write an event's sales figures to JSON for a nightly report or monitoring job. Skip the dashboard copy and paste, and let the scheduled command run without a Monday reminder.
Post an on-sale alert into Slack, sync attendees into your own CRM, or let a webhook start a script of your own. Stable JSON output and documented exit codes make the CLI safe to call from any script or pipeline.
The same tool boots a Model Context Protocol server, so Claude Code and other assistants can read and change your events inside guardrails you set, not by driving a browser.
No API keys to request, no integration to configure, no separate account. The CLI signs in as you.
One npm install, on macOS, Linux or Windows. Node 20 or newer.
Opens your browser and handles two-factor sign-in. On a server, set a Personal Access Token instead.
Set the brand once for this machine, then every command works against it.
Your token is never one of those settings. Signing in stores it in your operating system's
keychain where available, or in the protected credentials file otherwise. A server can read it from
TICKET_FAIRY_API_KEY. A project
.ticketfairyrc can override the active profile and API address, so
review a project's settings before you use them.
If the same setting appears more than once, a flag wins over an environment variable, which wins over the
project file, which wins over your global config. Named profiles let one machine keep separate sign-ins for
separate environments.
The operational groups cover event, ticket, order and customer work. The remaining groups handle
automation, updates and extensions. Run any command with --help
for its flags and examples. Commands that read Ticket Fairy data support
--output json.
Vault commands are invitation only. They return read-only banking data for brands with Vault access. Ask your account manager about access for your brand.
Predictable output, clear errors, up to three retries and dry runs make the CLI practical in a nightly job. Add non-interactive mode so a missing value fails instead of waiting for an answer.
Commands that return Ticket Fairy data print a readable table in a terminal and switch to JSON when output is piped. Progress and logs go to stderr, so what you pipe is always pure data.
Ticket Fairy data and action commands use 0 for success, 1 for an unexpected error, 2 for a usage mistake, 3 for a network failure, 4 for authentication, 5 for not found, 6 for a conflict, 7 for rate limiting. Errors carry a stable code, a message and, where useful, a hint.
Supported creates and PATCH updates carry a generated idempotency key, so a retry within one CLI run does not repeat the change. For a POST or PATCH script you may run again, pass your own --idempotency-key. For 24 hours, repeating the same request with the same key returns the original response. PUT updates, deletes and token minting or rotation are not replayed.
--dry-run prints exactly what would be sent and stops there, so a bulk change can be reviewed before it touches a single order.
Set TICKET_FAIRY_API_KEY in the job's environment and add
--non-interactive so a missing input becomes exit code 2 rather than
waiting for input. Then the job runs unattended, and a failure exits with a code your scheduler
can act on. If you schedule an export that contains buyer data, keep it in approved access-controlled storage
and delete it on your organisation's retention schedule.
The CLI signs in as you, not as an application with extra powers. Your Personal Access Token carries your dashboard role and your brand or event scope. It cannot grant itself permission to issue refunds or reach another brand's data.
Tokens are named, so you can tell the deploy bot from your laptop. They expire, up to a year. They can be rotated with an overlap of up to seven days, so a pipeline keeps running while you swap the value over. The overlap ends when the old token would have expired anyway, so rotate before its last week rather than during it. And they can be revoked the moment a laptop goes missing.
Give each automation its own named token, a useful description and an expiry that matches the job. You can then review or revoke that access without disrupting your other work.
ticketfairy mcp turns the CLI into a Model Context Protocol
server, so Claude Code, Cursor and other assistants work with your events through structured tools instead
of guesswork. Same sign-in, same permissions, and a read-only mode to start with.
No, but it helps to be comfortable in a terminal. Core event, ticket, order and customer work is available in the dashboard too. The CLI adds repeatable commands, scheduled reports, direct API access and terminal helpers such as updates and shell completion.
It uses the same account, permissions and API for your event operations, then adds files you can keep, structured output, pipelines, plugins and a direct API command. Some connected-provider sign-ins still stay in the browser. The practical difference is repeatability: a command can run tomorrow, in a pipeline or against another event.
Your Personal Access Token carries the same role and brand permissions you have in the dashboard, so it cannot give a script any extra access. Tokens are named, expire (up to a year), can be rotated with an overlap of up to seven days, so a pipeline keeps running while you swap the value over. The overlap never outlasts the old token's own expiry, so rotate before the last week rather than during it.
Yes. Set TICKET_FAIRY_API_KEY and the CLI never prompts you to sign in. Add --non-interactive and a missing input becomes exit code 2 instead of a prompt that waits for input.
It is the same package. ticketfairy mcp starts a Model Context Protocol server on your own machine so an AI assistant can use selected commands as structured tools, with the same sign-in and the same permissions.
Command names and JSON fields can change between releases, so pin a version in scripts and pipelines. A pinned version means an upstream release can never surprise a pipeline you depend on, and you upgrade when it suits you rather than when we ship.
Ticket Fairy in full: online ticketing system, with the features, pricing and support behind this page.
Install the CLI, sign in with your existing account, and automate recurring setup and reports.
Questions about scripting your setup? Email [email protected].