Events
Batch Ingest Events
Send multiple usage events to FlexPrice in a single request
POST
Batch Ingest Events
Use this endpoint when batching usage events for high-volume ingestion or backfilling historical data. More efficient than individual event calls when you have multiple events to send.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/flexprice/flexprice/llms.txt
Use this file to discover all available pages before exploring further.
Use Cases
- High-volume event ingestion (logs, metrics, telemetry)
- Backfilling historical usage data
- Batch imports from data warehouses
- Scheduled bulk uploads
- End-of-day usage summaries
Request Body
Array of event objects to ingest. Minimum 1 event, maximum 1000 events per request.Each event object has the same structure as the single event endpoint.
Event Object Structure
Unique identifier for the type of event.
Your system’s unique identifier for the customer.
Optional idempotency key. Recommended for ensuring exactly-once processing.
FlexPrice’s internal customer ID. Optional if using
external_customer_id.ISO 8601 timestamp. Defaults to current server time if omitted.
Optional identifier for the event source.
Arbitrary key-value pairs with event metadata.
Response
Confirmation message:
"Events accepted for processing"Examples
Response Codes
Events accepted for processing. All events are queued and will be processed asynchronously.
Invalid request. Common issues:
- Empty events array
- More than 1000 events in a single request
- Missing required fields in one or more events
- Invalid timestamp format
Missing or invalid API key.
Internal server error. Events were not accepted.
Limits
- Batch size: 1-1000 events per request
- Rate limits: Same as single event endpoint (per-API-key limits apply)
- Payload size: Recommended max 10MB per request
Best Practices
- Optimal batch size: Use 100-500 events per request for best performance. Larger batches reduce HTTP overhead but may timeout.
-
Include event IDs: Always provide unique
event_idvalues for idempotency, especially for retries. - Handle partial failures: If the entire batch fails, consider splitting it into smaller batches and retrying.
- Order matters for backfills: When backfilling, send events in chronological order (oldest first) to ensure accurate billing period calculations.
- Monitor ingestion lag: Use the monitoring endpoint to track processing delays during high-volume ingestion.
- Validate before sending: Check event structure locally before making the API call to avoid rejecting entire batches.
Backfilling Historical Data
When importing historical usage data:Related
- Ingest Single Event - Send one event at a time
- Query Events - Retrieve ingested events
- Meters - Configure how events are metered
Batch Ingest Events