Events API
Complete guide to sending and managing events
Events API
The Events API lets your application record usage events that drive metered features, credit consumption, analytics dashboards, and real-time entitlement checks. It is the primary ingestion endpoint for all customer activity and is therefore a prerequisite for the Entitlements API documented in Entitlements API.
Overview
• Single Event Ingestion – POST /api/events
• Batch Event Ingestion – POST /api/events/batch
(up to 1000 events per request)
• Historical Query – GET /api/events
(filter by customer, event name, date range, …)
• Back-fill – POST /api/events/backfill
(internal tool for migrating data – merchant authenticated)
All requests are merchant-scoped and require the same authentication scheme used throughout the API.
Idempotency Events supply an optional
idempotencyKey
. The platform stores the key for 24 h to guarantee at-most-once ingestion. Duplicate keys are accepted with HTTP202
and silently ignored.
Event Object
Field | Type | Required | Description |
---|---|---|---|
idempotencyKey | string | Uniquely identifies the event within 24 h. Auto-generated when omitted. | |
eventName | string | ✓ | Slug of the metric/feature you are tracking (e.g. api-call ). |
customerId | string | ✓* | Internal customer identifier. |
extCustomerId | string | ✓* | External customer identifier from your own system. |
eventValue | number | Numeric value for metered events (e.g. tokens used). | |
eventString | string | Free-form string value (e.g. file type). | |
properties | object | Additional JSON payload for analytics. | |
eventTimestamp | string (ISO-8601) | Defaults to current time when omitted. |
*One customer identifier is required, either customerId or extCustomerId.
Endpoints
Ingest Single Event
POST https://api.getlumen.dev/v1/events
{
"eventName": "image-generation",
"customerId": "cust_123",
"eventValue": 1,
"idempotencyKey": "evt_001" // optional
}
Successful ingestion returns:
{ "message": "Event accepted" }
202 Accepted
is returned because the event is persisted asynchronously.
Errors
Status | Reason |
---|---|
400 | JSON validation error |
500 | Idempotency or storage fail |
Ingest Batch of Events
POST https://api.getlumen.dev/v1/events/batch
{
"events": [
{
"eventName": "api-call",
"customerId": "cust_1",
"eventValue": 1,
"idempotencyKey": "call_001"
},
{
"eventName": "api-call",
"customerId": "cust_1",
"eventValue": 1,
"idempotencyKey": "call_002"
}
]
}
The response summarises processed vs duplicate events:
{ "message": "Batch received. Processed 2 new events." }
Duplicates (events whose idempotencyKey
already exists) are skipped and reported in the message string.
Query Events
Retrieve historical events for analytics or debugging.
GET https://api.getlumen.dev/v1/events?eventName=image-generation&customerId=cust_123&limit=100&startDate=2024-01-01&endDate=2024-01-31
Query Parameters
Parameter | Type | Description |
---|---|---|
eventName | string | Filter by event name |
customerId | string | Internal customer ID |
startDate | ISO date | Inclusive start of time range |
endDate | ISO date | Inclusive end of time range |
limit | number | Max rows to return (default = 1000) |
Example response:
{
"data": [
{
"eventName": "image-generation",
"idempotencyKey": "evt_001",
"customerId": "cust_123",
"eventValue": 1,
"properties": { "size": "1024x1024" },
"eventTimestamp": "2024-01-15T12:34:56Z"
}
]
}
Back-fill (Admin Only)
POST https://api.getlumen.dev/v1/events/backfill
Migrates older PostgreSQL data into QuestDB. The endpoint is not intended for general use; access is restricted to authenticated merchants and typically executed via CLI tooling.
Body
Field | Type | Default | Max | Description |
---|---|---|---|---|
batchSize | number | 500 | 5000 | Number of rows per iteration |
cutoffSeconds | number | 60 | Only events older than now-cutoff secs | |
merchantId | string | – | Limit back-fill to a single merchant |
Response:
{ "scanned": 1200, "inserted": 1189 }
Relationship to Entitlements API
The Entitlements engine consumes the aggregated usage derived from the events you send here.
For metered features (value
is numeric) the allowance versus usage is evaluated in real-time. Sending accurate events therefore ensures that:
- Usage Limits in the Entitlements API are correct.
- Credit depletion and expiry behave as expected.
- Analytics dashboards reflect customer activity.
No additional integration steps are required – once events are recorded, entitlement checks will automatically include the latest usage totals.
Best Practices
- Choose stable
eventName
s – changing the slug creates new metrics. - Send events immediately – delays reduce the accuracy of real-time limits.
- Include an
idempotencyKey
when retrying failed requests. - Batch when possible to reduce network overhead.
- Validate input on the client side to avoid 400 errors.
Error Handling Cheat-Sheet
Status | Meaning | Recommended Action |
---|---|---|
202 | Accepted, processing asynchronously | You’re good! |
400 | Validation failed | Fix the payload |
401 | Authentication or merchant missing | Check API keys / session |
500 | Storage / idempotency / Redis error | Retry with same idempotencyKey |
Changelog
Version | Date | Notes |
---|---|---|
v1 | 2024-06-XX | Initial release of Events API |