An event ticketing integration needs to keep orders, payments and customer records consistent across the systems your team uses. An API provides access to supported operations; webhook notifications help another system react to changes. Evaluate the documented contract, permissions and recovery behavior together.
A payment notification may arrive while your CRM is unavailable. The integration needs to record it, recover later and avoid creating the same customer twice, with a way to find the payment if the notification never arrives. That failure case makes the reliability requirements concrete.
Begin with the integration you actually need
Write one sentence per use case. For example:
- “Create an event in the ticketing platform from our CMS.”
- “Show current availability on our own public page.”
- “Create or update a contact after a permitted purchase.”
- “Reconcile payment status with our finance system each night.”
- “Notify our operations service when a particular documented event occurs.”
Each sentence should name the source of truth, data owner, update direction, acceptable delay, and what happens when the dependent system is unavailable. This prevents a team from buying a generic API to solve a requirement it has never specified.
The production checklist
| Area | Questions a developer should be able to answer from docs and a test account |
|---|---|
| Authentication | How are credentials created, scoped, rotated, and revoked? |
| Resources | Which objects can be read or written, and what are their stable identifiers? |
| Permissions | Which scope is needed for each endpoint and who can grant it? |
| Pagination | How do list responses paginate and how is incremental sync performed? |
| Writes | Is there an idempotency mechanism or documented duplicate protection? |
| Errors | Which status codes, validation errors, and retry guidance are documented? |
| Rate limits | What limits apply and what should a client do when it reaches one? |
| Change policy | How are versions, breaking changes, and deprecations communicated? |
| Testing | Is there a safe test account, sandbox, or realistic non-production path? |
| Audit and reconciliation | How can you prove and repair the final state after a failure? |
If an answer is not documented, treat it as unknown until the vendor gives a written, current answer. “It has worked for other customers” is not an integration contract.
Webhooks are notifications, not a complete ledger
A webhook can reduce delay, but it should not be the only source of truth for payments, admission, or irreversible workflow. A receiver should store the notification, identify it, process it safely, and reconcile against an authoritative resource or scheduled export according to the vendor’s contract.
The important questions are practical:
- Which event types exist today?
- Does delivery have a signature or another authenticated verification method?
- Are retries made, for how long, and under what conditions?
- Can the same message be delivered more than once?
- Is ordering guaranteed?
- What timeout applies to the receiving endpoint?
- Can missed messages be replayed, or must the client reconcile through the API?
- What is the schema and versioning policy for payloads?
Do not put an unverified webhook straight into a financial or access-control decision.
Gomry's API and webhook contract
The Gomry API sits at https://www.gomry.com/api/v1. Keys are created in Organization Settings and sent in the X-API-KEY header; each key carries a scope map, none, read or write, per resource. Resources cover spaces, events, experiences, recurrences, ticket classes, attendees, contacts, lists, forms, applications, payments and custom fields. Paginated list endpoints return page information; other endpoints have their own response limits. Read the API documentation.
Gomry documents two webhook delivery paths with different event lists and delivery rules. Read the webhook contract for their payloads and configuration.
Webhook subscriptions through the API or Zapier
For a new integration, create an HTTPS subscription through the API for one supported event type. It can optionally be limited to a particular event or form. The API key needs read access to the resource carried by that event. Gomry's Zapier app uses these subscriptions for its New Attendee, New Form Response and Updated Form Response instant triggers; using those triggers does not require calling the subscription API yourself.
The supported events are:
attendee.registered: a free or paid checkout registration, on web or app, with one event per ticket. Registrations awaiting approval are included; manually added guests and RSVP responses such as “maybe” or “not going” are excluded.form_response.created: a submitted form or application, excluding drafts.form_response.updated: a change to an already submitted response, including acceptance or rejection.
Each delivery has an event ID that stays the same across retries. Verify the HMAC-SHA256 signature over the timestamp and raw request body using the subscription secret, with the documented five-minute timestamp check. Keep that verification separate from confirming the current business state: an authenticated notification can still describe an earlier state.
Return a 2xx response within 10 seconds. A timeout, network failure, HTTP 429 or 5xx can cause up to three additional attempts with backoff. Other 4xx responses are not retried; a 410 response removes the subscription. Redirects are not followed. Deliveries can repeat or arrive out of order, so deduplicate by the envelope's event ID. Revoking the creating API key stops deliveries; removing its required read scope pauses them until access is restored.
Legacy organization webhook URLs
Existing dashboard-configured organization URLs receive the legacy events: payment.succeeded for a completed one-time payment, subscription.created, subscription.deleted, and form-response creation or updates. Every configured URL receives the organization's events without the subscription route's per-event filtering. Payment and subscription events are not part of the API/Zapier subscription event list above.
This route is best effort, unsigned and has a five-second timeout with no delivery retries. Treat its payload as advisory and verify sensitive payment details through the Payments API using payment.id. Legacy form-response messages may omit type; identify them through formID and applicationID, rather than assuming the subscription envelope.
Neither documented event list includes a check-in notification. Read attendee records through the API when the integration needs current check-in status.
A safe receiving pattern
The exact implementation depends on your stack, but the operating pattern should be recognisable:
- Apply the verification appropriate to the delivery path. For Gomry subscriptions, verify the signature against the raw bytes before parsing the JSON. Validate the format, then durably store or enqueue the accepted notification within that path’s timeout.
- Return a successful response after that durable handoff. Avoid acknowledging a message that exists only in process memory.
- Process it from the queue, keeping only the payload and metadata needed for the workflow and avoiding secrets in logs.
- Make the consumer idempotent: a repeated delivery should not create repeated consequences.
- Fetch or reconcile the current authoritative state before a consequential action. Signature verification establishes the source of a subscription notification; it does not establish that an older message still represents the current state.
- Record the outcome, alert on failures, and operate a scheduled backfill for missed notifications.
For Gomry subscriptions, use the envelope event ID to deduplicate retries. For legacy payloads, use available identifiers such as payment.id or applicationID together with the change being processed; do not discard a later update merely because it concerns the same record. Scheduled reconciliation recovers gaps after an outage: subscription retries are finite, while legacy organization URLs make no retries at all.
API versus hosted checkout versus embed
| Approach | Best when | You own |
|---|---|---|
| Hosted page or link | Speed, supported payments, and lower engineering burden matter most | Content, links, analytics, and customer support handoff |
| Embed | The on-site journey needs tighter visual continuity | Performance, accessibility testing, analytics, and integration troubleshooting |
| API-built flow | Custom product logic is a genuine advantage | Security, validation, errors, policy, ongoing maintenance, and support |
With Gomry, your developers build an API integration on the existing configurable product. Gomry does not offer enterprise or white-label solutions or commissioned development of a bespoke ticketing system. Use the least complex supported approach that satisfies the business requirement. An API is not a quality marker if it transfers payment or event-day reliability to a small team that cannot operate it.
Test plan before launch
Run a test with a real integration environment. Exercise expired credentials, insufficient scopes, validation error, duplicate processing, pagination beyond the first page, rate limiting, endpoint timeout, temporary downstream outage, API recovery, and a webhook that never arrives. Then show how the system repairs the final state.
Add a business test too: a customer buys, changes, is refunded, or arrives at an event. Identify which system is authoritative at each point and how support staff find it. Technical correctness that cannot be supported is not operationally complete.
Frequently asked questions
Why does idempotency matter?
Networks retry, users repeat actions, and messages can be delivered more than once. Idempotent handling prevents one intended outcome, such as creating a record or triggering a communication, from happening twice.
Are webhooks enough for synchronization?
Usually not alone. They can provide prompt notification, but robust integrations also have a reconciliation and backfill path for late, duplicate, or missed delivery.
Is an API safer than an embed?
Neither is inherently safer. An API can create powerful custom flows but gives your team more responsibility for authentication, validation, data protection, error handling, and support. Choose based on the actual requirement and operational capacity.
What should be documented before engineering starts?
The use case, data map, source of truth, permissions, expected volume, failure handling, retry and reconciliation policy, privacy obligations, and owners for support and incident response.
Can a vendor roadmap satisfy a requirement?
Not for a launch-critical workflow. Decide against current, documented capabilities and contractual commitments. A future feature can be a bonus, not the dependency.
Begin with one read-only request and a test notification. Check the received record against the API, then deliberately stop the receiver and demonstrate how the integration finds what it missed. If the workflow includes an AI client, see the MCP operations guide.