Webhook

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

Webhooks are in beta. The payload format and delivery behaviour may change.

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.

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 API reference for the full payload and verification details.

Setup

1. Name the destination

   Click Add Destination, select Webhook, and enter a name (e.g. “Production API”). This is a label used in the dashboard.

2. 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.

3. 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.

4. 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.

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 API reference 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 three-dot menu on the destination card. Delivery resumes on the next sync.

Managing your webhook

From the three-dot menu on a webhook destination card 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).

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.

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

If your endpoint sits behind a firewall, allowlist the following range:

5.60.65.64/26

All webhook deliveries originate from this range.