Skip to main content

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 HTTP POST 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.
Webhook payloads are not currently signed, and there is no shared secret or signature header on this delivery path. Treat the data as advisory: keep your endpoint URL private, accept requests only over HTTPS, and confirm anything sensitive (such as payment amounts) against the Payments API using the payment.id from the payload before acting on it.

Event types

The type 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 event type, 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 a payment.succeeded event:

Example: form submission

Handling webhooks

Best practices

Return a 2xx within the 5-second timeout. Offload anything slow (emails, database writes, third-party calls) to a background job or queue.
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.
Payloads are unsigned. Before acting on money-related data, re-fetch it from the Payments API using the payment.id from the payload.
Most fields are optional and vary by event type. Always check for existence before reading nested values.