Skip to main content
Webhooks let your server react to events the moment they happen on-chain — without polling the API. When a payment is confirmed, an escrow is locked, or a stream runs dry, FlareHQ sends an HTTP POST to your registered endpoint with a signed JSON payload describing the event. This page explains how to register your endpoint, verify every delivery, and handle each event type correctly.

Register a Webhook Endpoint

1

Open Webhook Settings

In the FlareHQ Dashboard, navigate to Settings › Webhooks and click Add Endpoint.
2

Enter Your HTTPS URL

Provide the public HTTPS URL of your handler (for example, https://yourdomain.com/api/webhooks). FlareHQ will not deliver to HTTP or localhost URLs in production.
3

Save Your Webhook Secret

After saving, copy the Webhook Secret shown on the endpoint detail page. You will use this secret to verify that every incoming request genuinely originates from FlareHQ. Store it in your environment variables:
.env.local
4

Select Events (Optional)

By default your endpoint receives all events. Use the event filter to subscribe only to the types relevant to your integration.
You can also register and manage endpoints programmatically via POST /api/webhooks. See the API Reference for the full schema.

Webhook Events

Every event FlareHQ can emit is listed below. Each delivery POSTs a JSON body with the shape { id, type, data, createdAt }.

payment.completed

USDC has been received and confirmed at a checkout session. data contains the payment id, amount, currency, and recipient.

payment.failed

A checkout session expired or the on-chain transfer failed before confirmation. data includes the session id and a reason string.

escrow.created

A new escrow contract has been deployed and funded on Arc. data includes escrowId, amount, payer, and beneficiary.

escrow.released

Escrowed funds have been released to the beneficiary. data includes escrowId and the on-chain txHash.

dispute.created

A dispute has been raised against an escrow. data includes disputeId, escrowId, and the raisedBy address.

dispute.resolved

An arbiter has resolved a dispute. data includes disputeId, outcome (released or refunded), and the arbiter address.

stream.created

A new payment stream has been started. data includes streamId, ratePerSecond, sender, and recipient.

stream.stopped

A stream was manually stopped before it fully drained. data includes streamId, amountStreamed, and the stoppedAt timestamp.

stream.completed

A stream has fully drained — all funds have been delivered to the recipient. data includes streamId and totalStreamed.

Webhook Event Object Shape

Every delivery has a consistent top-level envelope regardless of event type:
string
required
Unique event ID. Use this to deduplicate retried deliveries — store processed event IDs and skip any you have already handled.
string
required
The event type string, for example payment.completed or escrow.released.
string
required
ISO 8601 timestamp of when the event was created.
object
required
Event-specific payload. Fields vary by type — refer to the event cards above for the key fields in each payload.

Verifying Webhook Signatures

FlareHQ signs every delivery with an HMAC and includes the signature in the x-flarehq-signature header. Always verify this signature before processing any event. This prevents a malicious actor from spoofing events by sending crafted POST requests to your endpoint.
Verify signatures against the raw request body bytes, not a parsed or re-serialized JSON object. Even a single whitespace difference will cause the HMAC to fail. See the examples below for how to read the raw body correctly in each framework.

Express

src/app/api/webhooks/route.ts

Next.js App Router

src/app/api/webhooks/route.ts

Retry Policy

If your endpoint returns anything other than a 2xx status — or times out after 30 seconds — FlareHQ will retry delivery automatically: After three failed attempts the event is marked as undelivered. You can inspect and manually replay undelivered events from Settings › Webhooks › Event Log in the Dashboard.

Best Practices

Return a 200 OK response as quickly as possible — ideally before doing any database writes or downstream API calls. If your handler takes too long, FlareHQ will treat it as a timeout and schedule a retry. Enqueue the event to a background job queue and acknowledge receipt immediately.
Network retries mean your handler may receive the same event more than once. Store the event.id in your database when you process an event and skip any delivery whose ID you have already recorded.
While you are building, log the full event object for every delivery. This makes it much easier to understand what fields are available for each event type before you write your business logic.
Keep a separate webhook secret for testnet and production. This way a misconfigured staging integration can never accidentally pollute production data.

Next Steps

SDKs

Install and configure the FlareHQ SDK for Node.js, React, or Python.

Errors & Troubleshooting

Understand error codes and resolve common delivery failures.

Escrow & Disputes

Learn how escrow and dispute events map to on-chain contract state.

Streaming Payments

Understand how stream lifecycle events fire as funds drip on-chain.