Ingest overview
Learn how ReportPlane authenticates, validates, queues, and delivers incoming data.
Ingest is the write side of ReportPlane. An application or device sends records to a runtime endpoint. ReportPlane checks the sender and data contract before accepting those records for delivery.
The ingest sequence
Every accepted request passes through these controls:
- Transport — HTTP, WebSocket, Syslog UDP, Syslog TCP, or Syslog TLS.
- Identity — an ingest client or ingest-capable API key is resolved.
- Authentication — the configured token, JWT, mTLS, or combined policy is checked.
- Network policy — allowed CIDRs are applied when configured.
- Resource scope — the identity must allow the requested data model.
- Validation — required fields and declared types are checked.
- Acceptance — valid records enter the durable spool.
- Delivery — batches are written to the model's destination.
Acceptance is not warehouse completion
HTTP ingest returns 202 Accepted after records are validated and accepted into the delivery path. Warehouse delivery happens asynchronously.
This distinction lets applications continue through short warehouse delays. Use destination statistics and Live Monitor to observe downstream progress.
Batch shape
HTTP and WebSocket ingest use an envelope with one schema and an array of records:
{
"schema": "page_view",
"data": [
{
"occurred_at": "2026-08-02T12:00:00Z",
"account_id": "acct_123",
"path": "/settings"
}
]
}
One request cannot mix models. Send separate requests for different schema keys.
Choosing a transport
| Transport | Choose it when |
|---|---|
| HTTP | You want simple request/response delivery or batches |
| WebSocket | You keep a connection open for a stream of messages and acknowledgements |
| Syslog UDP | The source only supports connectionless Syslog and occasional loss is acceptable |
| Syslog TCP | You need a reliable stream without client certificates |
| Syslog TLS | You need encrypted Syslog and possibly mTLS identity |