Feed a source
POST /api/v2/sources/{id}/feed-source — send one record at a time to a source you already created.
This is how data actually enters a source. You post a JSON record; Simetrik accepts it, groups it with the records that follow, and turns the batch into the file that reaches reconciliation.
POST /api/v2/sources/{id}/feed-source{id} is the source id returned when you created the source.
Headers
| Header | Required | Value |
|---|---|---|
x-api-key | Yes | Your API key. |
x-skt-workspace | Yes | Workspace the source belongs to. |
x-skt-account | Yes | Account id. |
Content-Type | Yes | application/json |
Body
One JSON object per call — a single record, not an array and not a batch. The fields are whatever your source's column mapping values point at; anything else you send is carried along and ignored.
{
"id": "a1",
"amount": 1500,
"payment": {"method": "card"},
"paid_at": "2026-09-14 10:22:01"
}source_id and sk-int-id are added to every record by Simetrik. If your own payload uses either name, your value is overwritten — rename the field before you send it.
Example
curl -X POST "$SIMETRIK_INGESTION_URL/api/v2/sources/61171/feed-source" \
-H "x-api-key: $SIMETRIK_API_KEY" \
-H "x-skt-workspace: 886" \
-H "x-skt-account: 23" \
-H "Content-Type: application/json" \
-d '{
"id": "a1",
"amount": 1500,
"payment": {"method": "card"},
"paid_at": "2026-09-14 10:22:01"
}'Response
{
"statusSkt": "Success",
"sk-int-id": "Yx8k2FGPIAMFa3A="
}| Field | What to do with it |
|---|---|
statusSkt | Success when the record was accepted. |
sk-int-id | Simetrik's id for this call. It's stored with the record — keep it in your logs and quote it in support tickets. |
Other fields may appear alongside these two. They come from the transport layer and aren't part of the contract, so don't build on them.
A successful response means the record was accepted, not that it reached reconciliation. Accepted records are grouped into a file first, and only that file goes through conversion and delivery. To learn the outcome, use status notifications.
Batching and timing
Records don't travel one by one. They accumulate per source and are closed into a file when the batching window fills up — by elapsed time or by accumulated size, whichever comes first. The window is configured per deployment and can run to several minutes, so treat ingestion as near-real-time, not instant.
Two consequences worth designing around:
- A record sent now may land in a file minutes from now. Don't poll for results right after posting.
- Records from the same source share a file, and the file is what the lifecycle and the notifications talk about. A single malformed record fails the conversion of the file it landed in — see File lifecycle.
Errors
| Status | What it means |
|---|---|
403 | Authorization failed. See Authentication. |
400 | The body wasn't valid JSON, or wasn't a JSON object. |
5xx | The record was not accepted. Safe to retry — nothing was stored. |
There's no deduplication: posting the same record twice produces two rows. If your producer can retry, give each record a field you can deduplicate on downstream.
Earlier API version
An earlier generation of these endpoints is still served: POST /v1/sources?id=<source id> feeds a source, and POST /v1/create-source creates one. Both require x-skt-account and x-skt-workspace. New integrations should use the /api/v2 paths on this page.