Set up events without repeating yourself
--from-file, so the payload is a file you keep and run again next time.Ticket Fairy CLI
ticketfairy drives events, tickets, orders, customers and
payouts from your shell, your scheduled jobs, or an AI assistant. Everything you can do in the
dashboard, you can script.
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.
# install once
$ npm install -g ticketfairy
# sign in with your Ticket Fairy account
$ ticketfairy login
# and you are working
$ ticketfairy event list
id name starts status venue
evt_9f21 Summer Fest 2027 2027-07-16 live Victoria Park
evt_7b30 Warehouse Sessions #14 2027-03-04 live Unit 9
evt_5c02 Sunset Rooftop Series 2027-05-22 draft The Deck
Sample output. Your events, your brands, your permissions.
Version 0.x, in active development. Pin a version in scripts.
Clicking is the right tool for a one-off change. It is the wrong tool for the same change made forty times, for a report someone has to remember to run, and for anything another system has to trigger on its own.
--from-file, so the payload is a file you keep and run again next time.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.
$ npm install -g ticketfairy
$ ticketfairy --version
Opens your browser and handles two-factor sign-in. On a server, set a Personal Access Token instead.
$ ticketfairy login
# on a server or in CI, use a token instead
$ export TICKET_FAIRY_API_KEY="…"
Set the brand once for this machine, then every command works against it.
$ ticketfairy brand list
$ ticketfairy brand use 12345
$ ticketfairy event list
Your token is never one of those settings. Signing in puts it in your operating system's
keychain, and a server reads it from TICKET_FAIRY_API_KEY. What the
config files hold is which brand, output format and API address to use, so a
.ticketfairyrc is safe to commit alongside your project. Settings
layer in a predictable order: flags beat environment variables, which beat that project file, which beats your
global config. Named profiles let one machine keep separate sign-ins for separate environments.
The command groups cover the same ground as the dashboard. Run any of them with
--help for the full list of flags and examples,
and expect the same JSON from all of them.
ticketfairy init
One-shot setup: log in, pick the active brand, choose a default output format.
ticketfairy auth
Log in and out, check who you are, and manage Personal Access Tokens.
ticketfairy brand
List your brands and set the one every other command works against.
ticketfairy account
Start identity verification, where the account and the event need it before publishing.
ticketfairy config
Read and write the settings this machine uses: brand, output format, API base, profiles.
ticketfairy event
Create, update, publish, postpone, cancel, reinstate, clone, delete, and read stats.
ticketfairy ticket
Ticket types for an event: list, create, update, delete.
ticketfairy addon
Add-ons such as parking, merchandise and VIP perks, including grouping and order.
ticketfairy table
Table types for venue and club events with table service.
ticketfairy order
List, inspect, refund, cancel free orders, mark as paid, and export.
ticketfairy customer
List, search, inspect and export customers.
ticketfairy invitation
Send, resend and cancel invitations, including from a CSV file.
ticketfairy promotion
Create and manage promo codes.
ticketfairy messaging
List and send messaging campaigns.
ticketfairy checkin
Read live check-in status for an event.
ticketfairy team
Invite team members, change their role, and revoke access.
ticketfairy tour
Group events into a single brandable run, and manage its members.
ticketfairy webhook
Webhooks scoped to an event, a brand or a tour.
ticketfairy vault
Read-only view of Vault banking: account, balance, cards, transactions, transfers.
ticketfairy asset
Upload artwork and files, and get back the CDN URL to use in a payload.
ticketfairy api
Call any Ticket Fairy API endpoint directly, with auth and retries attached.
ticketfairy manifest
Print the whole command tree as JSON, so a script or an agent can discover it.
ticketfairy mcp
Start the built-in Model Context Protocol server for AI assistants.
Vault commands are invitation only. They work for brands enrolled in the Ticket Fairy Card programme and return nothing for everyone else. Ask your account manager if you want in.
A command you can only run by hand is a command you will run once. These four guarantees are what make it safe to put in a nightly job.
--idempotency-key and re-running the same command is a no-op instead of a second refund or a duplicate event. Two things sit outside it: a delete is not replayed, so a retry answers not-found rather than success, and minting or rotating a token is never replayed because its answer carries the secret.--dry-run prints exactly what would be sent and stops there, so a bulk change can be reviewed before it touches a single order.#!/usr/bin/env bash
set -euo pipefail
EVENT=evt_9f21
# drop today's orders into a dated CSV, keeping the last good one
# until this run has actually written a new one
ticketfairy order export "$EVENT" --output csv > "orders.part"
mv "orders.part" "orders-$(date +%F).csv"
# keep a dated snapshot of the sales summary beside it
ticketfairy event stats "$EVENT" --output json > "stats.part"
mv "stats.part" "stats-$(date +%F).json"
Set TICKET_FAIRY_API_KEY in the job's environment and add
--non-interactive so a missing input becomes exit code 2 rather than
a question nobody is there to answer. Then it runs unattended, and a failure exits with a code your scheduler
can act on.
The CLI signs in as a real person, not as an application with its own powers. A Personal Access Token carries exactly the role and the brand or event scope that person has in the dashboard, so a script written by a door supervisor cannot issue refunds, and one written by a promoter cannot 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.
Wherever Ticket Fairy keeps a history of a record, a change made with a token is attributed to that person in it, exactly as if they had clicked it themselves. Orders, refunds and ticket changes carry that record.
# mint a token for a pipeline, shown once
$ ticketfairy auth tokens create "CI deploy bot" --expires-in 30d
# swap it out without breaking the pipeline: up to 7 days of overlap
$ ticketfairy auth tokens rotate 42
# audit which tokens are still in use
$ ticketfairy auth tokens list
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. If you would rather click, everything the CLI does is also in the dashboard. The CLI exists for the jobs clicking makes slow: repeating the same setup, exporting on a schedule, and connecting Ticket Fairy to your own tools.
It drives the same events, orders and API operations through the same API, so the day-to-day work you do in the dashboard you can script here. A few things stay in the browser, such as signing in to a connected provider. What the CLI adds is repeatability: a command can run again tomorrow, in a pipeline, or against a second event.
A Personal Access Token is scoped to one person and carries exactly the role and brand permissions that person has in the dashboard, so a script can never do more than the human who created it. 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 for anything. Add --non-interactive and a missing input becomes exit code 2 instead of a question nobody is there to answer.
It is the same package. ticketfairy mcp starts a Model Context Protocol server on your own machine so an AI assistant can use the same commands as structured tools, with the same sign-in and the same permissions.
Yes, with one precaution: pin a version in scripts and pipelines. Command names and JSON fields can still change between minor releases before 1.0, and a pinned version means an upstream release can never surprise a pipeline you depend on.
Ticket Fairy in full: online ticketing system, with the features, pricing and support behind this page.
Install the CLI, sign in with the account you already have, and let a script do the parts nobody enjoys doing twice.
Questions about scripting your setup? Email [email protected].