UniLink Webhook Events Reference (All Events You Can Subscribe To)

A complete reference of every webhook event UniLink can send — what triggers each one, what the payload looks like, and how to subscribe selectively.

UniLink webhooks cover every meaningful action a visitor or customer can take on your pages — from simply viewing a page to completing a purchase to cancelling a subscription. Knowing exactly which event to subscribe to and what data each payload contains is the key to building integrations that respond precisely to what matters to your business. This reference covers all available event types, their trigger conditions, and the structure of their payloads.

What Webhook Events Does

Every webhook payload from UniLink shares a common outer envelope structure. The id field is a globally unique identifier for this specific delivery — use it for idempotency checks. The event field is a dot-notated string identifying the event type (for example, order.created). The created_at field is an ISO 8601 UTC timestamp of when the event occurred. The data object contains the full resource that triggered the event — its fields vary per event type but always include the resource's id and the most relevant attributes.

Events are organized into categories that reflect the resource they describe. Page events (page.viewed) fire on visitor activity. Contact events (contact.created, contact.updated) fire when visitors opt in through your forms or when contact records change. Order events (order.created, order.completed, order.refunded) cover the full purchase lifecycle. Form events (form.submitted) fire for any form submission that is not a contact opt-in. Subscription events (subscription.created, subscription.cancelled) and payment events (payment.failed) cover recurring billing lifecycle moments.

When you register a webhook endpoint in the dashboard, you choose which event types it subscribes to. You can subscribe a single endpoint to all events (convenient for logging or general-purpose handlers) or restrict it to specific types (more efficient for purpose-built integrations). You can also register multiple endpoints and route different event categories to different services — for example, sending all order events to your fulfillment service endpoint and all contact events to your CRM endpoint.

How to Get Started

1. Go to Settings → Webhooks → Add Endpoint in the dashboard. Enter your endpoint URL and expand the event type selector.
2. Choose the specific events relevant to your use case. If you are building a fulfillment integration, select order.created and order.completed. If you are building a CRM sync, select contact.created and contact.updated.
3. Save the endpoint and copy the signing secret. You need this secret to verify that incoming payloads are genuinely from UniLink.
4. In your handler, read the event field from the JSON body first and route to the appropriate processing function based on its value.
5. Log the full payload during development. Store the raw JSON alongside the event type and timestamp so you can inspect real payloads and refine your handler logic without needing to retrigger events manually.

How to Use Webhook Event Types

1. page.viewed: Fires every time a visitor loads your UniLink page. The data object includes page_id, url, referrer, user_agent, and country. Use this for custom analytics pipelines or real-time visitor tracking dashboards.
2. contact.created / contact.updated: Fires when a new contact opts in or an existing contact's record changes. The data object includes contact_id, email, name, phone, tags, and custom_fields. Use this to sync contacts to your email platform or CRM in real time.
3. order.created / order.completed / order.refunded: Covers the full order lifecycle. order.created fires at checkout; order.completed fires when payment is confirmed; order.refunded fires when a refund is issued. The data object includes order_id, amount, currency, items, customer, and status.
4. form.submitted: Fires when a visitor submits any form on your page (excluding contact opt-in forms, which trigger contact.created instead). The data object includes form_id, page_id, and a fields object containing submitted field names and values.
5. subscription.created / subscription.cancelled / payment.failed: Covers recurring subscription lifecycle. subscription.created fires when a plan is purchased; subscription.cancelled fires on cancellation; payment.failed fires when a renewal charge fails. The data object includes subscription_id, plan_id, customer, and next_billing_date.

Key Settings

Get the Most Out Of Webhook Events

Build a central event log as your first webhook handler. Before writing business logic, create an endpoint that simply stores every incoming event payload in a database table with columns for id, event, created_at, and the raw JSON body. This log becomes your audit trail, your debugging tool, and the data source from which you can derive any business logic later without having to re-subscribe to historical events.

Use contact.created and contact.updated together to maintain a real-time mirror of your UniLink contact database in your own system. On contact.created, insert the record. On contact.updated, upsert it using the contact's id as the key. The contact.updated payload includes a changes map showing which fields changed — use it to avoid overwriting fields your system has updated independently.

Handle payment.failed events with a dunning workflow. When a subscription renewal fails, you typically want to notify the customer, retry the payment after a few days, and eventually downgrade access if retries continue to fail. The payment.failed event gives you the subscription_id, the customer email, and the number of retry_count — enough context to determine what stage of the dunning sequence to trigger.

Test all event types before going to production by using the "Send Test Event" button in Settings → Webhooks → [Endpoint] → Test. UniLink sends a synthetic payload for any event type you choose. This lets you validate your handler logic for events that are rare in production (like order.refunded) without needing to actually perform a refund during development.

Troubleshooting

• UniLink fires 10 event types across page, contact, order, form, subscription, and payment categories.
• Every payload has a common envelope: id, event, created_at, and event-specific data.
• Use order.completed (not order.created) to confirm payment before fulfilling orders.
• Filter events per endpoint to subscribe only to types your handler actually processes.
• Use the "Send Test Event" button in the dashboard to validate handlers for rare event types before going live.