Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.redbark.co/llms.txt

Use this file to discover all available pages before exploring further.

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

Enter your webhook URL

Click Add Destination, select Webhook, and enter the HTTPS URL where you want to receive transaction data. Plain HTTP is not supported.
2

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

Save the destination

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 5 consecutive failures.

​
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 view (accessible from the destination’s three-dot menu). If a delivery fails, Redbark retries with exponential backoff:
AttemptDelay
1stImmediate
2nd1 second
3rd3 seconds
4th9 seconds
  • 2xx responses are treated as successful. The consecutive failure counter resets.
  • 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.

​
Auto-disable

If a webhook fails 5 consecutive times (across separate sync runs), the destination is automatically disabled. You can re-enable it from the destination’s three-dot menu. Delivery resumes on the next sync. A single successful delivery resets the failure counter.

​
Managing your webhook

From the three-dot menu on a webhook destination card:
  • Deliveries: view the last 50 delivery attempts with status codes, duration, and errors
  • 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)
  • Re-enable: re-enable a disabled webhook (delivery resumes on the next sync)
  • Delete: remove the webhook destination
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
  • 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.