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