---
description: "Choose documented JSON resources, identify organizer-only workflows, and understand API coverage and compatibility."
group: "Build an integration"
order: 32
---

# API coverage and workflow limits

Choose the integration surface that matches your workflow.

## Documented resources {#documented-resources}

The [OpenAPI reference](/en-us/reference/overview) 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](/en-us/docs/integration-recipes.md) to connect operations. Public checkout and waiting-list signup use the [ticket shop](/en-us/docs/embed-ticket-shop.md). Only event detail currently has an explicit `/api/v2` resource; other documented operations use their existing organizer paths.

## Organizer workflows {#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](/en-us/docs/promo-codes.md) 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](/en-us/docs/check-in.md). |
| 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 {#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](/en-us/docs/stages.md) 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 {#compatibility}

The OpenAPI document version identifies a documentation revision; it does not version every server route. Read [developer updates](/en-us/changelog) 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 {#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](/en-us/docs/testing.md) separates those checks from mail delivery, payment-provider verification, binary downloads and continuous streams.