Appearance
Introduction
Platypus exposes a small, read-only public API for event data. It exists so you can show a venue's events on the venue's own website — typically feeding a custom listing, or alongside the iframe embeds.
Base URL
Every endpoint lives under the venue's tenant prefix:
https://platypus.tickets/t/{slug}/api/{slug} is the venue's tenant slug — the same one that appears in its public event pages (for example nbt in https://platypus.tickets/t/nbt/events).
There is no authentication. The API returns only data that is already public on the venue's event pages.
Response format
Responses use a JSON:API-style document structure — resources carry type, id, attributes, and links, attribute names are snake_case, and collection responses carry top-level data, links, and meta.
It is deliberately not a full JSON:API implementation. To save you reading the spec against reality:
| JSON:API feature | Supported? |
|---|---|
type / id / attributes / links.self resource shape | Yes |
application/vnd.api+json media type | No — responses are plain application/json |
?include= compound documents | No — occurrences are always embedded inline |
?filter[...]= | No |
?sort= | No |
?page[size]= | No — page size is fixed at 12 |
?page= (Laravel-style page number) | Yes, on the index endpoint |
Pagination
The index endpoint returns 12 events per page with Laravel's standard pagination envelope: links.first/last/prev/next and meta.current_page/last_page/per_page/total (plus meta.links for rendering pagers). Request further pages with ?page=2.
Visibility
The API applies the same visibility rules as the public event listing:
- Only published events appear. Drafts never do.
- Private events (unlisted, password-protected pages) never appear — not in the index, not by id.
- Cancelled events remain visible with
publish_status: "cancelled"and acancellation_reason, unless the venue chose to hide the cancelled listing — then the API returns them in neither the index nor the show endpoint (the show endpoint responds404). - Past-dated events drop off the index.
CORS
Browsers may call the API from exactly two origins: the Platypus site itself, and the venue's own configured website domain — the Site Domain in the venue's admin settings (served as https://{site-domain}). Requests from other origins get no Access-Control-Allow-Origin header and will be blocked by the browser. Each venue's allowance applies only to its own /t/{slug}/ paths.
If you're building for a venue and hitting CORS errors, the venue admin needs to set the Site Domain to the domain your page is served from — see Embedding on your site.
Endpoints
Two endpoints exist today:
| Method | Path | Purpose |
|---|---|---|
GET | /t/{slug}/api/events | Published, listed events (paginated) |
GET | /t/{slug}/api/events/{id} | One event by numeric id |
Full detail and real request/response examples: Event endpoints.
These examples can't drift
The JSON examples in this section are fixture files asserted byte-for-byte by the Platypus test suite against real API responses. If the API changes shape, the build fails until the examples are regenerated — what you read here is what the wire carries.