Webhooks
Webhooks let Gomry notify your own systems the moment something happens in your organization — a ticket is purchased, a subscription changes, or a form is submitted. Instead of polling the API, you register one or more HTTPS URLs and Gomry sends an HTTPPOST request with a JSON payload to each of them as events
occur.
Configuring webhook URLs
Webhook endpoints are configured per organization.1
Open your integration settings
Go to Organization Settings → Integrations in your Gomry dashboard.
2
Add your endpoint URLs
Enter one or more endpoint URLs, one per line. Every URL you add receives
a copy of every webhook event for your organization.
3
Save
Save your settings. New events will start being delivered to your endpoints.
Use an
https:// endpoint that is publicly reachable and responds quickly (see
Delivery & reliability). Webhooks are scoped to the
whole organization — there is currently no per-event subscription.How delivery works
Each event is sent as a separate HTTP request to every configured URL:
Your endpoint should respond with a
2xx status code as quickly as possible.
Do any heavy processing after acknowledging the request (for example, by
pushing the payload onto a queue), so you don’t hit the delivery timeout.
Event types
Thetype field identifies what happened. The most common event is
payment.succeeded, which fires when an attendee buys a ticket.
Some legacy form-response payloads omit the
type field but always include
formID and applicationID. Use the presence of those fields to identify a
form-response event.Payload structure
All events share one envelope. Fields are populated based on the eventtype,
so most are optional — always guard for missing values.
user object
payment object
Example: ticket purchase
When an attendee buys a ticket, your endpoint receives apayment.succeeded
event:
Example: form submission
Handling webhooks
Best practices
Respond fast, process later
Respond fast, process later
Return a
2xx within the 5-second timeout. Offload anything slow (emails,
database writes, third-party calls) to a background job or queue.Make your handler idempotent
Make your handler idempotent
Because there are no delivery guarantees and multiple endpoints can be
configured, design your handler so processing the same event twice is safe —
key off
payment.id or applicationID.Verify sensitive data against the API
Verify sensitive data against the API
Payloads are unsigned. Before acting on money-related data, re-fetch it from
the Payments API using the
payment.id from the payload.Guard for missing fields
Guard for missing fields
Most fields are optional and vary by event type. Always check for existence
before reading nested values.
