> ## Documentation Index
> Fetch the complete documentation index at: https://docs.redbark.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Webhook

> Receive transaction and trade data via HTTP POST to your own endpoint

<Info>
  Webhooks are in **beta**. The payload format and delivery behaviour may change.
</Info>

Webhooks deliver transaction and brokerage trade data to any HTTPS endpoint you control. Each time a sync runs, Redbark sends a signed JSON payload to your URL — one event per data type, distinguished by the top-level `type` field.

<Info>
  Webhooks support bank transaction syncs and brokerage trade syncs. Brokerage holdings are not sent to webhook destinations; use a Google Sheets destination if you need holdings snapshots. All payloads are signed with HMAC-SHA256. See the <a href="/api-reference/webhooks">API reference</a> for the full payload and verification details.
</Info>

<Info>
  Webhook payloads carry a few fields beyond the [common transaction fields](/destinations#transaction-fields): `account_id`, `local_date`, `merchant_category_code`, `reference`, and `extended_description`.
</Info>

## Setup

<Steps>
  <Step title="Name the destination">
    Click **Add Destination**, select **Webhook**, and enter a name (e.g. "Production API"). This is a label used in the dashboard.
  </Step>

  <Step title="Enter your webhook URL">
    Enter the HTTPS URL where you want to receive transaction data. Plain HTTP is not supported. IP literal hostnames are rejected, and any hostname that resolves to a private or internal IP is also rejected.
  </Step>

  <Step title="Generate and copy your signing secret">
    Click **Generate Secret**. A signing secret is displayed immediately. **Copy it now.** It is only shown once. Use this secret to verify incoming webhook signatures on your server.
  </Step>

  <Step title="Acknowledge the disclosure and save">
    Tick the CDR disclosure checkbox confirming you understand data sent to this webhook will leave the Fiskil/Redbark CDR environment and may not be recoverable after delivery. Then click **Save Destination**. Transaction data will be delivered to your endpoint on the next sync. If your endpoint is unreachable or returns errors, Redbark retries with backoff and auto-disables after a single failed delivery batch.
  </Step>
</Steps>

## How it works

On each sync, Redbark:

1. **Checks for previously delivered entities**: transaction and trade IDs that were successfully delivered before are tracked to prevent duplicates
2. **Sends new and updated entities**: a JSON payload is POSTed to your URL containing any new records (and, for transactions, status updates such as pending to posted)
3. **Chunks large syncs**: if there are more than 500 records, they are split into multiple requests of up to 500 each, delivered sequentially

Transactions and trades are delivered as separate events. Use the top-level `type` field — `transactions.synced` or `trades.synced` — to route the payload on your side.

Each request includes HMAC-SHA256 signature headers for verification. See the <a href="/api-reference/webhooks">API reference</a> for the full payload schema and verification guide.

## Delivery and retries

Each delivery attempt is logged and visible in the **Deliveries** tab on the sync detail page (`/syncs/[id]/deliveries`).

If a delivery fails, Redbark retries up to 3 attempts total with exponential backoff:

| Attempt | Delay     |
| ------- | --------- |
| 1st     | Immediate |
| 2nd     | 1 second  |
| 3rd     | 3 seconds |

* **2xx responses** are treated as successful.
* **429 (rate limit)** responses are retried.
* **Other 4xx responses** are not retried (the request is malformed or rejected).
* **5xx responses and network errors** are retried.

Requests time out after 30 seconds. **Timeouts are not retried** — the body has likely been received by the endpoint, so retrying would risk duplicate delivery. The attempt is recorded with a `timeout` status.

## Auto-disable

If a delivery batch fails (after exhausting retries), the destination is automatically disabled. You can re-enable it from the row menu on the destination's row in the [destinations](/destinations) list. Delivery resumes on the next sync.

## Managing your webhook

From the row menu on a webhook destination's row you can **Open**, **Rename**, **Re-enable** (when disabled), or **Delete** the destination.

URL and signing secret changes live on the sync settings page (`/syncs/[id]/settings`):

* **Edit URL**: change the endpoint (generates a new signing secret; copy it and update your server, then test)
* **Rotate Secret**: generate a new signing secret (copy it and update your server, then test)

The **Deliveries** view (last 50 attempts with status codes, duration, and errors) lives on the sync detail page (`/syncs/[id]/deliveries`).

<Tip>
  When you rotate your signing secret or change the URL, a new secret is generated and shown immediately. Update your server with the new secret before the next sync runs, or deliveries will fail signature verification on your end.
</Tip>

## Security

* **HTTPS required**: webhook URLs must use HTTPS to protect data in transit
* **No IP literals or private addresses**: IP literal hostnames are rejected, and hostnames that resolve to private, loopback, link-local, CGNAT, or multicast IPs are rejected. The check runs at create time and re-runs immediately before each delivery to narrow the DNS-rebinding window
* **HMAC-SHA256 signing**: every payload is signed so you can verify it came from Redbark
* **Replay protection**: the signature includes a timestamp; reject requests older than 5 minutes
* **Encrypted storage**: your signing secret is encrypted at rest with AES-256-GCM
* **Per-destination secrets**: each webhook destination has its own unique signing secret

## IP allowlist

Redbark does not publish static egress IPs for webhook deliveries. Requests are sent by a Cloudflare Worker and egress from Cloudflare's shared network, so the source IP can change between deliveries and cannot be safely allowlisted. If your endpoint sits behind a firewall, allowlisting a specific range risks blocking deliveries entirely and tripping the [auto-disable](#auto-disable) after a single failed batch.

Instead, verify that a request genuinely came from Redbark using the HMAC-SHA256 signature described above.