ForgeSendDocs

Webhooks

The Webhooks tab, next to API keys under the Developer group in Settings, registers URLs that ForgeSend calls in real time when workspace events happen — replies, bounces, opens, and more — instead of you polling the API for changes.

Registering an endpoint

Only a workspace owner can register or delete endpoints — anyone else sees "Only the workspace owner can register or delete webhook endpoints" in place of the form. Registering one takes a URL and at least one event type.

Webhooks — register — read only

Webhooks

Register a URL to receive real-time event notifications — replies, bounces, send failures, unsubscribes, opens, and clicks. Each delivery is signed; the signing secret is shown in full only once, at creation, and can never be displayed or recovered afterward.

Events — this endpoint will only receive what you select here

Register endpoint

Registration is disabled until the URL is non-empty and at least one event checkbox is checked. Right after registering, the signing secret is shown once, in the same amber-highlighted, copy-and-confirm treatment as a new API key: "Copy this signing secret now — it will not be shown again.", a monospace read-only field, a Copy button, and a Done, I've saved it confirm.

Signed delivery

Every delivery is a POST of { event, data } as JSON, with an X-ForgeSend-Signature header — an HMAC-SHA256 hex digest of the exact request body, using the endpoint's own signing secret.

Example delivery — read only

POST https://yourapp.com/webhooks/forgesend

Content-Type: application/json

X-ForgeSend-Signature: a3f9c1...e207b4

{"event":"REPLIED","data":{"campaignId":"cmp_...","contactId":"cnt_...","repliedAt":"2026-07-24T15:12:00Z"}}

To verify a delivery, compute the same HMAC-SHA256 over the raw request body using your endpoint's secret and compare it to the header — a mismatch means the request didn't come from ForgeSend. ForgeSend gives your endpoint 15 seconds to respond before treating the attempt as failed.

Retries

A failed delivery is retried automatically, but only for failures that look temporary — a 429 or any 5xx response, or a network error/timeout. Any other non-2xx response (a 4xx, for example) is treated as a configuration problem on the receiving end and isn't retried at all.

Retry timeline — read only
Attempt 1→ fails (retryable) →Attempt 2, +5 min→ fails →Attempt 3, +55 min→ fails →FAILED

Three attempts total, spanning about an hour: the first try, a retry 5 minutes after that fails, and a final retry 55 minutes after that. If all three fail, the delivery is marked FAILED and not tried again. Disabling an endpoint mid-flight fails any delivery already queued for it immediately, without retrying.

Managing endpoints

Every registered endpoint shows in a table — URL, subscribed events, status, and when it was created.

Registered endpoints — read only
URLEventsStatusCreatedDelete
yourapp.com/webhooks/forgesendRepliedBouncedEnabled9 Jul 2026Delete
ops.brightlanegroup.com/hooks/leadsInterestedDisabled22 Jun 2026Delete

With none registered, the table is replaced with "No webhook endpoints yet — Register one above to get started." The Status pill is itself the toggle — click it to flip between Enabled and Disabled; a toast confirms "Endpoint enabled." or "Endpoint disabled." Delete shows an inline "Sure?" / Yes / No confirmation, same as revoking an API key, and is a hard, permanent delete — there's no way to recover a deleted endpoint or its signing secret.

Deleting an endpoint is different from revoking an API key: a revoked key is soft-deleted and just stops working, but a deleted webhook endpoint's row is removed outright. Neither action affects deliveries already recorded before the change.

Where to go next

Next: Audit log