Webhooks

A webhook sends an HTTP POST to a URL you choose whenever a record in a subscribed table is inserted, updated, or deleted. It's the lightest way to react to Carbon in your own systems without polling the API.

Subscribable tables

You subscribe a webhook to exactly one table. The tables you can watch, by module:

For each webhook you choose which operations fire it — insert, update, delete — and at least one must be selected.

The payload

Carbon POSTs a JSON body to your URL. type is the operation, record is the affected row, and old carries the previous row on updates and deletes.

{
  "type": "UPDATE",
  "table": "salesOrder",
  "companyId": "abc123",
  "record": { "id": "...", "salesOrderId": "SO000042", "status": "To Ship and Invoice" },
  "old": { "id": "...", "salesOrderId": "SO000042", "status": "Draft" }
}

On an insert, old is omitted; on a delete, record is the row as it last existed. The only request header is Content-Type: application/json.

Configuration

Create and manage webhooks under Settings → Webhooks. A webhook has:

• Name — a label, unique within your company.
• Table — the one table to watch.
• URL — where the POST is sent; must be a valid URL.
• Triggers — any of insert, update, delete (at least one).
• Active — webhooks are on by default; switch off to pause delivery.

Carbon tracks a success and error count per webhook, with the timestamp of the last of each, so you can see at a glance whether your endpoint is healthy.

Delivery & reliability

Delivery is at-most-once: Carbon fires a single POST per change and records the outcome. There are no automatic retries, no backoff, and no rate limiting on outbound calls — if your endpoint is down when the event fires, that delivery is missed (the success/error counters will show it). Build your consumer to tolerate the occasional gap, and reconcile against the API when it matters.

Related