Skip to main content
Our Webhooks API lets your application receive real-time updates whenever customers, transactions, or counterparties change in Conduit. You can register an HTTPS endpoint, and Conduit will deliver event notifications to it automatically. This means your application stays updated without constant polling.

Key Concepts

Webhooks

A webhook is a URL that Conduit will call when certain events occur. For example, when a transaction is created, Conduit will call the webhook URL with the transaction details.

Events

An event is a specific action that can occur in Conduit. For example, a transaction can be created, updated, or deleted.

Ways to configure Webhooks

We offer two ways to configure and manage webhooks on your account

Via the conduit Dashboard

  • Login into your Conduit Dashboard
  • Click Webhooks in the navigation menu to view, create, or manage endpoints.
You need to have developer permissions to see this section on the dashboard. Reach out to your account manager for access if you don’t.

Via the Webhooks API

  • Use our Webhooks API to programmatically create, update, list, or delete webhook endpoints.
  • See the API Reference for request and response examples.
Your webhook endpoint must accept JSON payloads and respond with a 200 OK status quickly to prevent retries and timeouts. Conduit will retry delivery up to 10 times over 24 hours before marking the event as failed.

Supported Webhook Events

Conduit supports the following webhook event notifications, grouped by resource type.

Counterparty Events

These events notify you of changes in a counterparty’s lifecycle from activation to compliance checks.

Counterparty Statuses

The counterparty object within the payload will have one of the following statuses:

Customer Events

These events track important customer status updates — including onboarding progress, compliance checks, and KYB status.

Transaction Events

These events cover the full transaction lifecycle — from creation to settlement — including compliance decisions and payment processing.

Transaction Statuses

The transaction object within the payload will have one of the following statuses, reflecting its current state in the lifecycle:

Understanding Webhook Payloads

Webhook event payloads contain the full resource object (transaction, customer, or counterparty) at the time of the event. The structure and data types of these objects match exactly what you would receive from the corresponding API endpoints.

Payload Structure

Each webhook payload follows this structure:
Using event_timestamp and event_sequence:
  • Use event_timestamp to determine when an event occurred and to detect stale events
  • Use event_sequence (when present) to detect out-of-order delivery and ensure correct processing order
  • Events with a higher sequence number occurred after events with a lower sequence number within the same event stream

Understanding Data Types and Fields

The data types, field names, and structure within the webhook payload are identical to what the corresponding API endpoint returns. This ensures consistency across our API and webhooks. For detailed field documentation:

Example: Counterparty Webhook Payload

When a counterparty.active event occurs, the webhook payload contains the full counterparty object.

Example: Transaction Webhook Payload

When a transaction.awaiting_compliance_review event occurs, the webhook payload contains the full transaction object. Below are examples for different transaction types.

1. Offramp Transaction

4. Conversion Transaction

2. Onramp Transaction

Onramp transactions include an onRampInstructions field containing details for the deposit.

3. Withdrawal Transaction

Withdrawal transactions include a blockchainTxHash once processed on-chain.

7. New Onramp Transaction

5. Deposit Transaction

Crypto deposit transactions include a blockchainTxHash once the transaction is confirmed on-chain.
The transaction object in the webhook payload has the exact same structure, field names, and data types as the response from the Get Transaction API endpoint. Refer to that API reference for complete field documentation.

Best Practices

The following are the list of best practices that you need to have in place to for a smooth integration with our webhook.

1. Handle Idempotency with conduit-webhook-idempotency-key

Every webhook request from Conduit includes a unique conduit-webhook-idempotency-key header.
Use this key to ensure that the same event is not processed more than once.
Recommended approach:
  • Read the header value from the request.
  • Check if this key was already processed in your system.
  • Skip processing if the key is found (to prevent duplicate effects).
  • Store keys temporarily in a database or cache (e.g., Redis)
  • Clean up old keys periodically.
Why it’s important:
Webhook retries can occur due to network issues or failed acknowledgements.
Idempotency ensures that your system processes each event only once, preserving data integrity.

2. Verify Webhook Signatures

Always validate webhook signatures to ensure:
  • The request truly originated from Conduit.
  • The payload has not been altered in transit.
Additional security measures:
  • Replay attack prevention – validate the timestamp in the webhook header conduit-signature-timestamp and reject requests that are too old (e.g., older than 5 minutes).
  • Constant-time comparison – compare the expected and actual signatures in constant time to prevent timing attacks.

3. Respond Quickly

Return a 200 OK status as soon as possible. If processing takes a long time, consider deferring it to a background job.

IP Address Whitelisting

For an additional layer of security, you can restrict incoming webhook requests to only those originating from Conduit’s official IP addresses. This ensures that only Conduit can trigger your webhook endpoint, reducing the risk of unauthorized requests. Why Whitelist IPs?
• Prevents webhook spoofing from unknown sources.
• Adds an extra security layer alongside signature verification.
• Useful for organizations with strict network access controls.

What’s next?