41 REST endpoints over the whole product: three to get a key, then thirty-eight behind it covering schedules, sub-schedules, events, recurrences, ticket types, sales and refunds, appointment booking, boost requests, feedback and fan content. JSON in, JSON out, one header.
An OpenAPI 3.0 spec, llms.txt and agents.json ship with it, so an agent can discover this API and drive it without a human reading the docs first.
{ "name": "Analog Night", "starts_at": "2026-08-14 20:00:00", "duration": 3, "tickets_enabled": true, "tickets": [{ "type": "Advance", "price": 18, "quantity": 120 }] }
{ "data": { "id": "Kd3Vq7", "url": "https://synth-lab.eventschedule.com/analog-night/Kd3Vq7", "tickets": [{ "id": "9pR3vB", "type": "Advance" }] }, "meta": { "message": "Event created successfully" } }
That one call also writes the event to Google, Outlook or CalDAV if the schedule is connected to one, and fires an event.created webhook.
No SDK to install, no OAuth dance, no sandbox to request. The whole surface behaves the same way, which is the only property an agent really needs.
Register, generate a key in your settings, or log in when you have none. Keys last a year. Nothing else is required.
300 reads and 30 writes a minute, per account. Over the line you get a 429, not a silent drop.
100 by default, 500 at most, with a meta block carrying the page, the total and the bounds. Categories and sub-schedules come back whole.
Never a sequential integer, and an event's is the same string that appears in its public URL, so you can build a link from a response.
{ "data": [ ... ], "meta": { "current_page": 1, "total": 50 } }
{ "error": "Validation failed", "errors": { "starts_at": ["must match Y-m-d H:i:s"] } }
401 for a bad key, 403 when the plan or the permission is missing, 404, 409 when a key is already live or a refund's outcome is not yet confirmed, 422 with the offending fields named, 429 when throttled. A model can branch on that without guessing.
41 endpoints. Not a summary of them, all of them. Everything past /api/login needs the key header, and API access is part of the Pro plan.
| Method | Path | Behaviour |
|---|---|---|
| Auth No key required. Each of these has its own throttle. | ||
| POST | /api |
Mail a six-digit verification code. Hosted mode only, five per address per hour. |
| POST | /api |
Create the account and return a key. Three per IP per hour. |
| POST | /api |
Mint a key for an account that has none. A live key returns 409 instead. |
| Schedules A schedule is the tenant: a venue, a talent or a curator. | ||
| GET | /api |
List the schedules you own or administer. Filter by name and by type. |
| GET | /api |
One schedule, with its sub-schedules inlined. |
| POST | /api |
Create one. name and type are required; the subdomain is generated from the name. |
| PUT | /api |
Name, contact, description, timezone, language, address. Partial payloads are fine. |
| DELETE | /api |
Marks it deleted, so it and its pages go dark. Owner level only, not admin. |
| Sub-schedules Named strands inside one schedule, each with its own colour. | ||
| GET | /api |
id, name, slug and colour for each sub-schedule. |
| POST | /api |
name is required, colour optional. The slug is generated. |
| PUT | /api |
Rename it or recolour it. |
| DELETE | /api |
Events survive; their sub-schedule reference is cleared. |
| Events The big one. Tickets, agenda parts, members and recurrence all ride along. | ||
| GET | /api |
Paginated, newest first. Twelve filters, including tickets_enabled, is_cancelled and your own external_id. |
| GET | /api |
One event with its tickets, members and agenda parts. |
| POST | /api |
Create an event on a schedule, or with an external_id and upsert, update the one you made last time. Carries its own 30-per-minute throttle. |
| PUT | /api |
Partial update. Recurrence, tickets and agenda parts survive being omitted. |
| DELETE | /api |
Delete it, and withdraw it from any synced calendar. |
| POST | /api |
Call it off and keep its sales. Optionally email the people registered, with a note. |
| POST | /api |
Undo a cancellation. Nobody is emailed. |
| POST | /api |
Multipart upload of a flyer_image for an existing event. |
| Categories Read-only lookups so you can send a category_id you know exists. | ||
| GET | /api |
Every system category, with its id and name. |
| GET | /api |
The effective list for one schedule, including its own custom categories. |
| Sales A sale is a buyer, a set of ticket quantities and a status. | ||
| GET | /api |
Filter by event, subdomain, status, buyer email or occurrence date. |
| GET | /api |
One sale with its ticket lines. |
| POST | /api |
Book a sale by hand. Created unpaid; free tickets are marked paid straight away. |
| PUT | /api |
mark_paid, cancel or refund. A refund sends Stripe, PayPal or Razorpay money back, in full or an amount you name; an idempotency_key makes a retry safe. |
| DELETE | /api |
Soft delete. It stops appearing in listings. |
| Feeds Read-only, for pulling audience content onto a site you already run. | ||
| GET | /api |
Post-event star ratings and comments. Filter by minimum rating and date range. |
| GET | /api |
Approved comments, photos and videos. Submitter email addresses are never included. |
| Appointments For an agent that books on a guest's behalf, a voice agent on the phone line most often. | ||
| GET | /api |
The types a guest can book, with price, host, questions and the next open time. |
| GET | /api |
Open times as UTC instants, each with a sentence in the schedule's timezone to read out. |
| POST | /api |
Book one. A taken time answers 409 with the three nearest; an Idempotency-Key makes a retry safe. |
| Boosts For a network that runs its schedules' boosts under its own Facebook Page and ad account, with the account's own key. | ||
| GET | /api |
Every request on the network's schedules. updated_since keeps a checkout in step without polling each one. |
| GET | /api |
One request: the exact ad and its version, the approval, the payment, the spend. |
| POST | /api |
Approve a named version. A stale version answers 409, so earlier wording can never launch later wording. |
| POST | /api |
Send it back with a note the business reads. |
| POST | /api |
Record your own Stripe reference and amount. Approved and paid launches it. |
| DELETE | /api |
Withdraw a payment confirmation before launch. |
| POST | /api |
Pause it at Meta and end it. |
| GET | /api |
The monthly statements of the fee on actual spend. |
| GET | /api |
One month: each campaign's spend, fee and adjustment. |
Full documentation for each one, with a cURL example and a response body, is in the API reference.
Documentation written for a person is a bad input for a model. These four are written for the model, live at fixed paths, and are served from any installation, hosted or your own.
The short one. What Event Schedule is and what each plan includes, links to the main product, audience, comparison and documentation pages, and the API essentials: the auth header, which plan the API needs, the rate limits and a getting-started sequence, so an agent can decide in one fetch whether this API is relevant at all.
The whole reference in one file, so an agent never has to follow a link to finish a task. Every endpoint, every parameter, every error shape.
Named multi-step flows: register_and_setup, create_event_with_tickets, sell_tickets, manage_schedule and book_appointment. Each one lists its calls in order, so a plan is data rather than prompt engineering.
The machine-readable spec. Generate a client, or generate tool definitions, in whatever language your agent is written in.
Filtering a calendar, standing up a weekly residency, and settling a sale. Everything else is a variation on these.
?subdomain=synth-lab &starts_after=2026-08-01 &tickets_enabled=1 &per_page=50
"meta": { "current_page": 1, "last_page": 2, "total": 63 }
Twelve filters on the events list, including whether tickets or RSVP are switched on, whether an event is cancelled, a venue, a sub-schedule, a date window and the id your own system gave the event. You narrow server-side rather than pulling a year and filtering in the agent.
"schedule_type": "recurring", "recurring_frequency": "weekly", "days_of_week": "0111110", "recurring_end_type": "after_events", "recurring_end_value": "14"
"schedule_type": "recurring", "days_of_week": "0111110"
A seven-character mask, Sunday first, so Monday to Friday is "0111110". Frequency is one of daily, weekly, every_n_weeks, monthly_date, monthly_weekday or yearly, and a run can end never, on a date, or after a set number of occurrences.
{ "action": "mark_paid" }
"status": "paid", "payment_amount": 36, "total_quantity": 2, "tickets": [{ "type": "Advance" }]
Three actions, and which ones are legal depends on where the sale is: mark_paid from unpaid, refund from paid, cancel from either. On a Stripe, PayPal or Razorpay sale, refund sends the money back before the status moves, and an amount makes it partial, which leaves the sale paid. You can also create a sale outright for a buyer who paid you off-platform.
You can name a venue or a performer instead of looking up an ID: send venue_name with venue_address1, or members as a list of names and emails, and the API resolves them to schedules on your account. To be exact about what that is: it matches an existing schedule you own or follow, and returns a 422 naming the one it could not find. It does not invent a venue for you. Categories work the same way: send category as a name and it is matched against that schedule's category list.
Polling a sales endpoint every minute is a waste of both our time. Register an endpoint and the traffic reverses: we POST to you, signed, the moment something happens.
X-Webhook-Event: sale.paid X-Webhook-Signature: sha256=<hex> X-Webhook-Timestamp: 2026-08-14T20:11:04+00:00 User-Agent: EventSchedule-Webhook/1.0 { "event": "sale.paid", "data": { ... } }
The signature is an HMAC-SHA256 of the raw body, keyed on a secret shown once when you add the hook. Verify it before you trust the payload. Key on data.id plus the event type, because a delivery can repeat and one sale fires several types. There is a delivery log in your settings when something goes wrong.
Details that only matter once your code is running unattended, which is exactly when they matter most.
Event Schedule is open source, and the API does not change when you host it yourself: same routes, same OpenAPI spec, same discovery files, served from your own domain. On a selfhosted install the Pro gate returns true unconditionally, so no endpoint is held back and no key talks to anyone else's server.
Send a flyer_image_url with the event and the picture is fetched and stored with it, in the same call. A file of your own is multipart, so it gets its own request: POST a flyer_image to the flyer endpoint with the returned ID.
curl -X POST .../api/events/flyer/Kd3Vq7 \ -H "X-API-Key: $KEY" \ -F "[email protected]"
Set language_code on a schedule and its pages are served in that language; twelve are supported. A schedule can also nominate one translation target, and its own copy is machine-translated into it on a scheduled pass.
Ticket types created through the API sell through your own Stripe or PayPal account, or through Invoice Ninja, Payfast for rand prices, Razorpay for Indian rupee (INR) prices, a payment URL, or by hand. Event Schedule takes zero platform fees on ticket sales: the only deduction is your processor's. Sales come back through the sales endpoints and through sale.paid webhooks, with the ticket lines attached, and a Stripe, PayPal or Razorpay refund goes back through the provider.
Two endpoints exist purely so you can pull audience content somewhere else: post-event ratings and comments, and approved fan photos, videos and comments. Fan submissions carry a display name only; the ratings feed names the attendee, so treat it as owner-facing.
Each kind of fan submission has its own ID sequence, so key on type and id together when you store a row.
PUT takes the same body as create and applies only what you send. Recurrence configuration, ticket types and agenda parts are preserved when they are absent, so an agent that only knows the new start time cannot quietly erase a run's ticket tiers. Every write is scoped to the schedules the key's owner owns or administers, and anything outside that returns 403 rather than silently doing nothing.
An HTTP API has no opinion about what is calling it, which is the point.
Turn a conversation into a published event. Register, create the schedule and create the event in three calls, then hand back the URL from the response.
Learn more →A cron job, a CLI, a one-off migration. Generate a client from the OpenAPI spec and the whole surface is typed for you.
Learn more →A Discord, Slack or Telegram bot that creates the event when someone announces it in the channel, and posts the ticket link back.
Learn more →Keep your own front end and let Event Schedule hold the events, the ticket types and the sales. Webhooks push each paid sale straight back to you.
Learn more →Pull a date window with the events filters, or take the iCal feed and skip the API entirely. Both come off the same schedule.
Anything that speaks HTTP and JSON. If you would rather not write the client, the OpenAPI spec will write it for you.
Learn more →One unauthenticated POST to /api/register, or to /api/register/send-code first in hosted mode. The response body carries the key and its expiry.
X-API-Key: es_live_...
POST /api/schedules with a name and a type. The subdomain is generated from the name and the public page exists immediately.
{"name": "Synth Lab", "type": "venue"}
POST /api/events/{subdomain}. Ticket types, agenda parts and recurrence go in the same body, so there is no second round trip. On eventschedule.com this one needs the schedule on Pro.
{"name": "Analog Night", "duration": 3}
Free registration for as many people as you like. When you start charging, zero platform fees on every plan - the only deduction is your payment processor's own.
Everything you need to publish a schedule and fill the room, for as long as you like.
No expiry, and no card asked for.
Start charging, and the rest of the selling kit arrives with it.
7-day free trial, cancel any time.
For a room with a seating chart, a team, and a domain of its own.
Included free on every selfhosted install.
What developers ask before they write the first request.
The REST API is part of the Pro plan at $5 a month, with a seven-day trial when you subscribe. Selfhosted installations are Pro by definition, so running your own copy unlocks every endpoint at no cost. Ticket sales carry zero platform fees on every plan and in both modes: you keep everything except your payment processor's cut.
On eventschedule.com the list endpoints for schedules, events, sales and feedback return only rows from schedules on Pro, so a free schedule's data is missing rather than refused: check the plan before you read an empty list as nothing there. Reading one schedule, event or sale, updating a schedule, and writing to its events, sub-schedules or sales return 403 with "API usage is limited to Pro accounts". The exception worth planning around is POST /api/sales, which has no plan check of its own: a free schedule can record a sale against a zero-price ticket, while any row with a price on it needs the schedule to be Pro and answers 422 otherwise. On a selfhosted install every one of these checks passes.
One header, X-API-Key. Get a key from POST /api/register or POST /api/login, or generate one in your account settings. Keys are valid for a year. Login only mints a key when the account has none, and returns 409 while one is still live, so store the key rather than calling login on every run. Accounts with two-factor authentication have to generate keys from the web UI. Every endpoint except register, send-code and login requires the header.
41 endpoints across registration, schedules, sub-schedules, events, categories, sales, appointment booking and boost requests, plus two read-only feeds for post-event feedback and fan-submitted content. A network that boosts its schedules under its own Facebook Page approves, declines, records payment for and stops those boosts, and reads its monthly fee statements, with its own key. Schedules, sub-schedules, events and sales have full create, read, update and delete; categories are read-only lookups. A single create call can carry ticket types, agenda parts, performing members, a venue and a recurrence pattern, so publishing a run of shows is one request rather than six.
Yes: PUT /api/sales/{id} with the action refund. On a Stripe, PayPal or Razorpay sale the money goes back through the provider before the status changes. Send an amount to return part of it, and the sale stays paid with its tickets valid; leave it out and the whole remaining balance goes back, the sale becomes refunded, its places return to stock and sale.refunded fires. Send an idempotency_key of your own so a retry returns the first attempt's outcome instead of refunding twice. A refund whose outcome could not be confirmed returns 409 and is never retried for you. Invoice Ninja, Payfast, payment-link and cash sales are only recorded as refunded, so return that money yourself, and a payment plan is refunded in full only.
llms.txt is an emerging convention for telling a language model what a site is and where its documentation lives. Event Schedule publishes both: llms.txt is a short routing summary an agent can read to decide whether this API is relevant, and llms-full.txt is the entire reference in one file, so an agent that has decided to proceed never needs to follow a link.
300 GET requests a minute and 30 POST, PUT or DELETE requests a minute, counted per account, so callers that share an address do not share a budget. Requests with no key or a wrong one are counted per IP address. Creating an event carries its own 30-per-minute throttle on top of that, and the auth endpoints have their own tighter limits. Going over returns 429 with an error body.
There are webhooks, on the Pro plan. Fourteen event types cover sales, event changes, door scans, pass bookings and feedback. Each delivery is signed with HMAC-SHA256 in an X-Webhook-Signature header so you can verify it came from us, payloads match the shapes the API returns, and there is a delivery log in your settings for debugging.
Encoded strings, never sequential integers. An event, a ticket, a sale and a sub-schedule all identify themselves with a short opaque string, and an event's is the same string that appears in its public URL, so you can build a link straight from a response. Category IDs are the exception: they are small integers you read from the categories endpoint.
Yes. Event Schedule is open source and the API is the same in both modes: same routes, same spec, same discovery files served from your own domain. On a selfhosted install the Pro gate returns true unconditionally, so nothing is held back.
Pick a name and start, or register straight from your code. Publishing a schedule and its dates is free forever, and so is free registration; the API and any ticket with a price on it are $5 a month, and Event Schedule takes nothing from the door.
No card to start. Or go straight to the API reference and the OpenAPI spec.
{ "name": "Your Agent", "email": "[email protected]", "password": "..." }
{ "data": { "api_key": "your_new_api_key", "api_key_expires_at": "2027-07-30T00:00:00Z" } }
In hosted mode, POST /api/register/send-code mails a six-digit code first, and you pass it as verification_code.
We'd like to use optional cookies for analytics and for marketing, including maps and videos from other sites. Nothing optional is set until you choose. The organizer of a schedule page you visit also sees visits to it, without your name. Learn more