Webhooks for account events.
Register an HTTPS endpoint in app.data.co and receive signed events when usage thresholds are reached, your subscription changes, Control approvals are requested, or API keys change. Register endpoints under Administration › Webhooks; dataset events are planned.
Events you can subscribe to
| Event | When it fires |
|---|---|
| usage.threshold_reached | A monthly plan meter reaches 80% or 100% of its limit. |
| subscription.updated | Plan or subscription status changes: checkout, upgrade, payment failure, cancellation. |
| approval.requested | A Data.co Control policy requires human approval for a request. |
| approval.decided | An approval is approved or denied. |
| policy.activated | A Control policy version is activated. |
| api_key.created | An API key is created. |
| api_key.revoked | An API key is revoked. |
Payload and signature
Each delivery is a JSON event with a unique id. The Data-Co-Signature header carries a timestamp and an HMAC-SHA256 of the timestamp and raw body, computed with your endpoint's signing secret. During secret rotation the header carries a signature for both the new and the previous secret.
{
"id": "evt_…",
"object": "event",
"type": "usage.threshold_reached",
"api_version": "2026-11-01",
"created": 1793000000,
"organization_id": "<org id>",
"data": { … }
}
// Header:
// Data-Co-Signature: t=<unix seconds>,v1=<hex hmac>Illustrative example · final API surface documented in /docs
Receiving webhooks
- 1
Register an endpoint
In app.data.co › Administration › Webhooks, add an HTTPS URL and choose the events it should receive. The signing secret is stored encrypted.
- 2
Send a test
Use Send test to deliver a webhook.test event and confirm your signature check passes.
- 3
Verify every delivery
Recompute the HMAC over the raw request body, compare in constant time, and reject timestamps older than your tolerance. Five minutes is a sensible default.
- 4
Respond fast, process later
Return a 2xx quickly and queue the work. Anything other than 2xx, or a network error, is treated as a failure and retried.
- 5
Deduplicate
Store event ids you have processed. A retry delivers the same id, so handling must be idempotent.
Backoff and failure
Failed deliveries are retried with exponential backoff, starting at one minute and doubling up to a cap of twelve hours, for up to ten attempts. After the last attempt the delivery is marked dead and shown in the delivery log, where it can be re-queued.
Every attempt re-checks the endpoint URL against server-side request forgery protections, so endpoints that resolve to private or internal addresses are blocked rather than delivered.
Dataset events under consideration
Not in the catalog yet. Tell us whether these would fit your integration.
| Event | When it would fire |
|---|---|
| dataset.updated | A dataset you follow publishes a new version or its schema changes. |
| dataset.access_changed | An access method's status changes, for example REST becomes available. |
| download.ready | A requested export has been prepared, rights permitting. |
What teams wire webhooks to
Spend and quota alerts
Post usage.threshold_reached to a chat channel or paging system at 80% and 100% of a monthly meter, before integrations start failing with quota_exceeded.
Key inventory
Mirror api_key.created and api_key.revoked into your secrets inventory or SIEM, so key changes are visible outside app.data.co.
Approval routing
Forward approval.requested from Data.co Control to the tool where approvers already work, and record approval.decided alongside the request.
Billing sync
Update internal cost-center records when subscription.updated reports a plan change or a payment failure.
Hardening your receiver
Verify the signature against the raw request body before parsing it; re-serialized JSON will not match. Reject deliveries whose timestamp is outside your tolerance to limit replay, and keep a store of processed event ids so a replayed or retried event is handled once.
Treat the payload as a notification, not as authority. For anything consequential, such as a plan change, confirm the current state from app.data.co or the API before acting. Keep the signing secret in your secret manager, and rotate it when people with access to it leave.
Questions buyers ask
Can I receive webhooks today?
Yes. Add an HTTPS endpoint in app.data.co under Administration › Webhooks and choose its events. Dataset events are still planned.
Is ordering guaranteed?
No. Use the created timestamp and event id, and design handlers so that events arriving out of order do not cause harm.
How do I rotate the signing secret?
Rotate it in the dashboard. For a period, deliveries are signed with both secrets, so you can deploy the new secret before the old one stops being used.
Will dataset access changes be announced another way?
Yes. Until dataset events exist, access status changes are shown on each dataset page and in the catalog's per-channel status.
What does a receiver need to return?
Any 2xx status within a short time. Return quickly and do the work asynchronously; slow or non-2xx responses are retried.
Can one endpoint receive several event types?
Yes. Each endpoint subscribes to the events you choose, and the type field in each payload tells your handler which one arrived.
API and MCP access is live.
Sign up at app.data.co, create an organization and issue a scoped key for REST and MCP.