Events
Poll the events of a company, list the event types and test webhooks locally with the CLI.
Overview
Every change that fires a webhook is also stored as an event (evt_...). The Events API lets you read them: catch up after downtime, reconcile your system, or build a local integration without a public URL. The data of an event is exactly the data your webhook endpoint receives for that type.
Events are part of the core API (no module needed), but types that belong to an optional module are only available while that module is on.
The Event Object
| Event field | Webhook envelope field |
|---|---|
id | id (the same id, use it to deduplicate) |
type | event |
created_at | created_at |
data | data |
test | test (true for test events; data.test is also true) |
Endpoints
| Method | Path | Permission | Description |
|---|---|---|---|
GET | /v1/events | read | List events, newest first (type, created[gte], created[lte], resource_id) |
GET | /v1/events/{id} | read | Retrieve an event |
GET | /v1/events/types | read | Event types available for the company, with an example payload |
POST | /v1/events/test | write | Create a test event (not delivered to webhooks) |
List Events
typeis an exact type (invoice.paid), a prefix wildcard (invoice.*) or*. An unknown type returns400 invalid_typecreated[gte]andcreated[lte]accept ISO 8601 (2026-10-11or2026-10-11T15:30:00Z) or unix seconds. URL-encode the brackets if your HTTP client requires it- Results use cursor pagination (
limit,starting_after,ending_before) and are always newest first
To poll for new events, request created[gte]=, skip the ids you already handled and process the rest oldest first. This is exactly what corebill listen does.
Event Types
GET /v1/events/types returns the types available for the company (types of disabled modules are left out). It is not paginated. Each entry has a label, a description, the module that owns it (null for core events), whether it can trigger automations, and an example of its data.
Create a Test Event
POST /v1/events/test stores an event of any available type with its example payload, test: true and resource_type: "cli_test". It shows up in GET /v1/events (so corebill listen picks it up) but it is never delivered to your webhook endpoints and does not run automations.
Errors: 400 parameter_missing without type, 400 invalid_type for an unknown type and 400 event_type_unavailable when the type belongs to a module that is turned off.
Test Webhooks Locally
You do not need a public URL to build your webhook endpoint. corebill listen follows the events of the active company and forwards each one to your local server with the same body and Corebill-Signature header as a real webhook, signed with a local secret.
- Install the CLI and log in:
npm install -g @corebill/cliandcorebill login - Start the listener pointing at your local endpoint:
corebill listen --forward-to localhost:3000/webhooks/corebill - Copy the
whsec_...secret it prints into your.envasCOREBILL_WEBHOOK_SECRET. It stays the same for this company on this computer - In another terminal, trigger an event:
corebill trigger invoice.paid(or do something real in the dashboard)
Your endpoint verifies the forwarded request exactly like a production webhook: HMAC-SHA256 of with the whsec_... secret, compared with the v1 value of Corebill-Signature. In production, use the secret of your webhook destination instead (Settings > Developers > Webhooks).
--events invoice.*,payment.receivedforwards only those types (wildcards allowed)--print-jsonprints the full event;--print-secretprints the secret and exits- If your server is down, the error is shown and the listener keeps running
- Forwarded requests carry
test: truefor test events; check it if your handler must ignore them