An event-ticketing integration is not complete because it can create an event or display a ticket count. In production it has to withstand retries, duplicate messages, incomplete delivery, permission mistakes, reconciliation, and the uncomfortable moment when a customer’s money or admission depends on a stale record.
Evaluate the documented contract and failure behaviour, not an integration logo wall or a reassuring sales sentence.
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.
What Gomry publicly documents
Gomry’s API introduction describes organisation-scoped API keys and documents resources including events, attendees, and ticket classes. Read the current API introduction for the documented scopes and endpoints. That supports a clear positioning: Gomry is useful for experience businesses that need ticketing data to participate in their own operating stack, not merely sit behind a hosted event page.
Gomry’s separate webhook documentation currently describes five event types, configured per organisation. It says delivery is best effort, with a five-second timeout, and that payloads are not signed and deliveries are not retried. Read the webhook contract directly. Those constraints are not a defect to hide; they define the architecture you must build. If you need signed delivery, retry guarantees, or a scan-related event, treat it as a requirement to confirm with Gomry rather than inferring it from a different product page.
For sensitive workflows, reconcile through the documented API on a schedule and keep your own durable record of when a notification was received and processed.
A safe receiving pattern
The exact implementation depends on your stack, but the operating pattern should be recognisable:
- Receive the message quickly and return the response required by the vendor’s documented timeout.
- Store the raw body and enough metadata to identify the delivery, without logging secrets or unnecessary personal data.
- Enqueue durable processing rather than doing complex work in the request path.
- Make the consumer idempotent: a repeated delivery should not create repeated consequences.
- Fetch or reconcile the current authoritative state before a consequential action if the event contract does not guarantee full, ordered, signed delivery.
- Record the outcome, alert on failures, and operate a scheduled backfill for missed notifications.
This is why webhook capability should be assessed with reliability requirements, not a yes/no feature box.
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 |
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 synchronisation?
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.