How to Configure Outbound Webhooks for Real-Time Data Syncing

Overview: This article covers how to configure Grip's Outbound Registration Webhooks. This feature enables customers to configure their own HTTP endpoints to receive event-driven registration notifications directly from the platform.

This allows for real-time syncing with third-party systems, reducing the need for multiple custom integrations. You can configure the webhook with different event triggers, select between a simple or full data payload, and set up various authentication methods for enhanced data security. Failed webhook requests are logged and automatically retried, and manual retries are also supported.

Table of Contents:

• Use cases and information
• Before you begin configuring Grip Outbound Webhooks
• How do you use/configure Grip Outbound Webhooks?
• Troubleshooting Webhook Delivery
• Frequently Asked Questions

Understanding Grip Outbound Webhooks Grip Outbound Webhooks provide support for customers to configure their own HTTP endpoints that receive registration notifications driven by events within our platform.

What is the basic premise of Outbound Webhooks? The core premise is to allow real-time syncing of registration data with third-party systems. This feature uses a dedicated queue (QUEUE_OUTBOUND_WEBHOOK) and a worker application to process and deliver outbound webhook requests asynchronously to the configured endpoints.

What are the key benefits from Outbound Webhooks? The integration allows for real-time syncing with external systems. It also mitigates the need for creating custom integrations for multiple platforms. It provides a very flexible way to set up data transfer from Grip to almost any external platform.

Who can use Outbound Webhooks? Event organizers using Grip Manage can configure multiple webhooks for their event. New endpoints for this feature are intended for use within the Admin Dashboard.

Before you begin configuring Grip Outbound Webhooks Before configuration, you must have an endpoint URL ready on a third-party system that is capable of receiving HTTP requests. Note that the requestUrl field must validate and accept the https protocol only.

You can find the feature in Grip Manage under Event Settings and then Integrations, where you will see a tab called Outbound Webhooks.

How do you use/configure Grip Outbound Webhooks? Customers can configure multiple webhooks per event. When creating a new webhook, you must provide several key pieces of information:

1. Name and Description: Provide a name for the webhook and an optional description.
2. Request Method and URL: Specify the request method, typically POST, but PATCH or DELETE are also supported. Enter the Request URL(s)—the endpoint on the third-party system that will receive the webhook events.
3. Event Triggers: Select the action(s) that will trigger the outbound request. Currently, the supported triggers are registration.created, registration.updated, and registration.deleted.
4. Payload Format: Choose between a simple ID or a full payload.
   • Simple Payload: Sends only non-PII fields: registrationId, eventId, and action. This is preferable for security-conscious clients. If more data is needed, the recipient service must call the Register API for the full profile information.
     
     
   • Full Payload: Sends the registrationId, eventId, action, and a data object containing key information from the person and ticket documents. This can include PII data like firstName, lastName, email, phone, company, and jobTitle.
     
     
5. Authentication Method: Although not all platforms support it, authentication is highly recommended for data security. Supported authentication types include:
   • No Auth.
   • Auth token sent via querystring (e.g., <webhook_endpoint>?x-api-key=some-token).
   • Auth token sent via request header (e.g., X-API-KEY: some-token or Authorization: Bearer ).
   • Note: HMAC shared secret authentication may be included in a V2 release.
6. Manage/Activate: Once configured, you can enable/disable or delete the webhook.

Troubleshooting Webhook Delivery Grip provides comprehensive logging and retry mechanisms for delivery attempts.

• Retry Logic: Failed requests are automatically retried twice with exponential backoff (e.g., after 1 minute and 2 minutes). Transient errors (5xx or network issues) trigger these retries.
• Failure Statuses: Requests in the automatic retry process have a failedRetrying status. Those that fail after the maximum retries or encounter permanent failures (4xx responses) are marked as failedPermanent.
• History Log: You can view detailed logs of every webhook transaction in the Admin Dashboard history log. Logs are kept for a retention period of 30 days. The history log allows you to view the request payload and the response received.
• Manual Retry: Failed webhooks can still be manually retried by an Admin Dashboard user via the History Logs tab, for example, if the client has fixed an issue on their side.

Frequently Asked Questions Q: What data is included in the webhook events? A: The data included depends on the payload format selected. The simple payload includes only non-identifiable data (registration ID, event ID, action). The full payload includes PII such as email, name, and company, but this carries a risk of PII data leakage if misconfigured.

Q: What happens if the webhook fails? A: Failed requests are automatically retried twice using exponential backoff. If the attempts fail, the event is marked failedPermanent, but it can still be manually retried by an administrator.

Q: Are all event triggers supported? A: Currently, only registration events (registration.created, registration.updated, registration.deleted) are supported. Other triggers, such as purchase events, session updates, or company creation, are slated for future release.