REST API.

Two things you call from your code: ingest events, and read or write entities. Sources, destinations, and pipelines are configured in the dashboard — they don't have a public API surface. One bearer key covers both.

Auth

One bearer key.

# bearer key in the Authorization header
$ curl https://in.ingestlayer.com/v1/ingest \
    -H "Authorization: Bearer $INGESTLAYER_KEY" \
    -H "Content-Type: application/json" \
    -d '{ "events": [{ "type": "user.signup", "payload": { "email": "ada@example.com" } }] }'

# every endpoint is org-scoped — the key carries the org

Keys are minted at /keys in the dashboard. They carry the org they were issued in; nothing about cross-org access works.

Ingest

Send events.

Event ingest

• POSThttps://in.ingestlayer.com/v1/ingestSend a batch of events. Body: { events: [{ type, payload, idempotencyKey?, timestamp? }] }. Up to 500 events per call.

See the TypeScript SDK for the typed wrapper, or quickstart for body shapes. Returns 202 once your event is durable.

Entities

Read and write your identity graph.

Entities have their own endpoint set — upsert by (kind, external_id), list with filters, fetch one, patch traits, delete. Full reference, with examples for nightly CRM sync and one-off upserts, lives with the concept page.

→ entities · endpoint reference

Response shape

One envelope.

Every endpoint returns { "data": ... } on success or { "error": { "message": ... } } on failure. Status codes are conventional: 200/201 for success, 400 for validation errors, 401 / 403 for auth, 404 for not-found, 409 for conflicts, 5xx for server failures.

Everything else

Lives in the dashboard.

Sources, destinations, and pipelines are designed to be composed visually. There's no programmatic API for them — the dashboard is the interface. If you want to provision them from code, talk to us; we'll help you figure out whether you actually need that.