Skip to main content
Webhook destinations are generally available. Existing payload fields, signing, and delivery behaviour remain compatible. Additive fields may appear, so consumers should ignore unknown fields.
Webhooks deliver bank and Documents transactions to any HTTPS endpoint you control. Each time a sync runs, Redbark sends a signed JSON payload to your URL with the top-level type set to transactions.synced.
Brokerage accounts currently sync only to Google Sheets, not webhook destinations. All webhook payloads are signed with HMAC-SHA256. See the API reference for the full payload and verification details.
Webhook payloads carry a few fields beyond the common transaction fields: account_id, account_public_id, local_date, merchant_category_code, reference, and extended_description. Use account_public_id to match a transaction to the same acct_… account returned by API v2.

​
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 IDs that were successfully delivered before are tracked to prevent duplicates
  2. Sends new entities: a JSON payload is POSTed to your URL containing records not already tracked as delivered. Ordinary syncs do not send same-ID transaction corrections in data.updated.
  3. Chunks large syncs: if there are more than 500 records, they are split into multiple requests of up to 500 each, delivered sequentially
Pending and posted transactions can have different provider IDs; Redbark does not guarantee a link between them. For a reconciled ledger, prefer posted-only syncs and periodically reconcile an overlapping date window through the transactions API. The payload reference also defines trades.synced, but Redbark does not currently allow a brokerage-to-webhook sync to be created. 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:
  • 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

One non-timeout delivery failure disables the destination, either after retries are exhausted or after a non-retried 4xx. A timeout does not disable it or stop the remaining chunks. A chunk that was not confirmed, whether it failed or timed out, marks the sync run as failed. The run’s counts include only rows from chunks your endpoint confirmed. You can re-enable it from the row menu on the destination’s row in the 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).
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

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 after a single failed batch. Instead, verify that a request genuinely came from Redbark using the HMAC-SHA256 signature described above.