credit.expired
Fired when a credit block's remaining balance expires (the block reached its expires_at). data is the expiry ledger entry; its amount is the millicredits written off. See credit.expiring_soon for the proactive lead-time warning.
When it fires
QuotaStack sends this when a credit block reaches its expires_at. A QuotaStack job finds the block and writes the expiry down. No API call raises this event.
When it does not fire
QuotaStack does not send this for a block that was already empty. A block you granted with no expiry never raises it. This event is the record of the expiry, not a warning before it. The warning is credit.expiring_soon, and it stays off unless you turn it on.
| Field | Type | Meaning |
|---|---|---|
idrequired | string (uuid) | |
tenant_idrequired | string (uuid) | |
customer_idrequired | string (uuid) | |
environmentrequired | string |
Which environment this resource lives in. Determined by the API key prefix used ( |
deltarequired | integer (int64) | Millicredits. Positive for credits, negative for debits. |
typerequired | string |
|
sourceoptional | string |
|
credit_block_idoptional | string (uuid) | |
billable_metric_keyoptional | string | |
cost_unitsoptional | integer (int64) | How many metric units this entry covers. An expiry charges nothing, so this reads 0. Unit: a count of billable metric units, not credits. |
exchange_rateoptional | integer (int64) | |
idempotency_keyrequired | string | |
reference_idoptional | string (uuid) | |
metadatarequired | object | |
created_atrequired | string (date-time) |
{
"event_id": "0192f5a4-7c31-7b8e-9a2d-4f6c8e1b3a51",
"event_type": "credit.expired",
"tenant_id": "0192f5a4-7c31-7b8e-9a2d-4f6c8e1b3a01",
"environment": "live",
"customer_id": "0192f5a4-7c31-7b8e-9a2d-4f6c8e1b3a05",
"external_customer_id": "user_42",
"created_at": "2026-07-28T12:22:00Z",
"idempotency_key": "expiry:0192f5a4-7c31-7b8e-9a2d-4f6c8e1b3a31",
"data": {
"block_id": "0192f5a4-7c31-7b8e-9a2d-4f6c8e1b3a31",
"credits_expired": 12000,
"balance_after": 61500
}
}What to do
Show the customer what they lost, and offer more. Watch for credit.exhausted right after this one, if the expiry emptied the balance.
Which calls fire this
- QuotaStack's scheduler, on a timer — no API call involved.
See also
Delivery
QuotaStack guarantees at-least-once delivery. An event may be delivered more than once if your endpoint returns a non-2xx response, the connection fails, or the request exceeds the delivery timeout.
Delivery timeout: 5 seconds per attempt. If your endpoint does not return a 2xx within 5 seconds, the attempt is treated as a failure and retried. Not configurable today.
One webhook URL per tenant. Multiple URLs and per-event routing are not supported. Configure the URL via the tenant config endpoint.
Retry schedule
If delivery fails (non-2xx response, timeout, or network error), QuotaStack retries with exponential backoff:
| Attempt | Delay after previous |
|---|---|
| 1 | Immediate |
| 2 | 30 seconds |
| 3 | 5 minutes |
| 4 | 30 minutes |
| 5 | 2 hours |
| 6 | 8 hours |
| 7 | 24 hours |
After 7 failed attempts, the event is moved to a dead letter queue. Dead-lettered events are not lost — you can requeue them yourself, from the dashboard (Activity → Webhooks → Redeliver) or the API:
curl -X POST https://api.quotastack.io/v1/webhooks/events/{event_id}/redeliver \
-H "X-API-Key: $QS_KEY" \
-H "Idempotency-Key: redeliver:{event_id}"
Redelivery resets the event to pending with a fresh retry schedule (7
new attempts). The next attempt signs with your current secret —
useful when the event dead-lettered because of a secret rotation or an endpoint
outage you have since fixed. Only dead_letter events can be
redelivered; the call returns 409 for events in any other status.
Handling duplicates
Because delivery is at-least-once, your webhook handler should be idempotent. Use
the webhook-id header for deduplication — if you have already
processed an event with that ID, return 200 and skip processing.
Loading…