Loading documentation…
{{ error }}
API coverage and workflow limits
Choose the integration surface that matches your workflow.
Documented resources
The OpenAPI reference covers organizer event configuration, products and availability, categories/questions, order and attendee actions, waiting-list administration, event promo codes/invitations, check-in, analytics, notes/directories, files, exports and stage state. Reads, writes, downloads and streams have different success formats and permissions.
Use integration recipes to connect operations. Public checkout and waiting-list signup use the ticket shop. Only event detail currently has an explicit /api/v2 resource; other documented operations use their existing organizer paths.
Organizer workflows
| Workflow | Current behavior | Integration approach |
|---|---|---|
| Company-wide promo codes | /company_promocodes provides company catalog, forms, activation/deactivation/deletion and CSV download. Creation is POST; edits and state actions accept PUT. Forms redirect and have no dedicated JSON serializers; a success message does not establish a normalized JSON contract. |
Use the organizer company promo-code UI. Event-scoped promo-code operations have published request/response formats. |
| Batch promo-code creation | Event creation accepts code_amount; the successful batch branch redirects without a structured list of created IDs. Bulk deletion has legacy redirect/message results. |
Use the batch organizer workflow. For JSON automation, create individual codes and retain each returned ID. |
| Complete promo-code catalog | The legacy event promocodes/index.json failed JSON verification. all_data only maps codes referenced by orders; unused codes can be absent. |
Keep returned creation IDs. The current reference does not offer a dependable full-detail catalog. |
| Attendee CSV import | /{event_id}/imports/attendees parses Csv.csv, previews validation, requires Csv.ok and send_invite confirmation, then redirects. Optional email creates delivery side effects. |
Use the organizer import preview/confirmation. It is not a stateless JSON bulk-create endpoint. |
| Barcode-scan CSV import | /{event_id}/imports/barcodescans validates pasted CSV and confirms the selected event before importing. |
Use the organizer import screen or the documented individual check-in API. |
| Refunds | orders/cancel_refund and refund_attendees prepare selections and confirmation, use payment capabilities/operation state, and call the payment provider. |
Use the organizer refund workflow. Cancellation and a provider refund are separate operations; a cancellation result does not prove that funds were returned. |
| Create paid orders, telesales and duplicate checkout | Checkout maintains cart, visitor/session and payment-provider state. | Use the ticket shop or organizer telesales UI. Existing order edits do not provide an arbitrary order-creation API. |
| Workshops and exhibitor tools | Registration options, workshop views and exhibitor lead capture have application-specific workflows. | Use published question/attendee resources for registration data; verify a separate contract before automating these UI tools. |
Callbacks and credentials
Payment-provider callbacks and HubSpot/Mailchimp authorization callbacks serve those providers' protocols. They are not a customer webhook subscription API. The current integration contract uses organizer HTTP Basic; it does not offer self-service API keys, token scopes, Paydro OAuth client registration or an official SDK. The four language samples in the reference are direct HTTP examples.
For order/attendee updates, use the documented snapshot/change resources and their recovery rules. Stage SSE only streams stage display state. A public API for webhook subscriptions, assured API credentials or provider refunds needs implementation and verification before documentation can promise it.
Compatibility and changes
The OpenAPI document version identifies a documentation revision; it does not version every server route. Read developer updates before changing your integration. Accept extra response fields, preserve UUIDs and historical data, and check legacy error envelopes. There is no published fixed deprecation notice period. Retired scanner actions and inferred generic v2 mutation routes are excluded; use the documented paths.
Verification boundary
Examples are synthetic and schema-validated. Selected reads are checked against local fixtures; isolated controller tests also verify successful note/category writes and persistence. Other successes and side effects are source-reviewed. Testing your integration separates those checks from mail delivery, payment-provider verification, binary downloads and continuous streams.