Utviklere

Hendelsesstrømmen

Pull-basert endringskonsum: konvolutten, markørpaginering, typefiltre, sjekkpunkter, og strøm mot webhooks.

Pull i stedet for push

GET /v1/events (omfang events:read) serverer de samme hendelsene som webhooks pusher, som en ordnet markørstrøm — riktig valg når integrasjonen ikke kan eksponere et HTTPS-endepunkt, eller når dere vil konsumere under egen planlegger.

curl -sS "https://api.itemra.io/v1/events?limit=50" \
  -H "Authorization: Bearer $ITEMRA_API_KEY"

Konvolutten

{
  "id": "evt_01…",
  "type": "stock.changed",
  "version": 1,
  "occurredAt": "2026-07-13T10:15:30Z",
  "organizationId": "org_01…",
  "data": {}
}

Hendelses-ID-er er stabile — de er dedupliseringsnøklene deres. Bruk occurredAt for domenetid (aldri ankomstrekkefølge), og ignorer ukjente felt så kompatible tillegg ikke knekker dere. Katalogen matcher webhooks: stock.changed, item.created, item.updated, movement.created, po.received, count.completed, low-stock, export.completed.

Markører og sjekkpunkter

Lagre page.nextCursor og send den uendret som cursor — også når data var tom: en filtrert tom side kan fortsatt flytte markøren forbi urelaterte hendelser. limit er 50 som standard (maks 200); ett enkelt type-filter snevrer strømmen.

Vil dere heller sjekkpunkte på hendelses-ID-er, bruk type=<hendelsestype>&afterEventId=<siste-id> i stedet for markør (aldri begge). Et ukjent eller utløpt sjekkpunkt returnerer et valideringsproblem, så dere nullstiller bevisst i stedet for å hoppe over i stillhet.

Velge mellom strøm og webhooks

Webhooks gir lavere forsinkelse og ingen pollingkost, men krever en herdet mottaker (signaturer, idempotens, tilgjengelighet). Strømmen gir konsum i eget tempo uten noe eksponert. Mange integrasjoner kjører begge: webhooks for fart, et nattlig strømsveip for sikkerhet.