Skip to main content
Most eTIMS operations don’t finish inside your HTTP request. They are accepted, processed, and the KRA result is confirmed shortly after. Understanding this is essential to building a robust integration.

​
Synchronous vs asynchronous

Connecting a company completes inline. Every write operation hands you a syncBatchId and continues processing in the background.

​
What syncBatchId represents

Every async operation creates a sync batch that tracks the lifecycle of the work:
When processing finishes, the batch is updated with the result (e.g. an ETR receipt for a sale) or a human-readable error.

​
How you track results

You have two reliable options.

​
1. Poll the read endpoints

For sales and catalog, poll the GET endpoints until the state you expect appears:
A sensible client polls with backoff for a few seconds — results typically confirm quickly.

​
2. Sync monitoring in the dashboard

The dashboard’s Sync Monitoring screen shows batches and their outcomes, including failures and error messages — useful while developing and for support. Sync monitoring — batches, items, and errors

​
Reliability

  • Exactly-once outcomes. Results are applied to a batch once, even if processing is retried internally — so a transient network blip won’t double-apply an outcome.
  • A failed batch carries a reason. When something goes wrong (e.g. insufficient stock, an unsynced item), the failure includes a human-readable message you can surface and act on.

​
Designing for async

  • Don’t block your user on the HTTP response. Treat syncBatchId as “accepted for processing”, then confirm out-of-band.
  • Be idempotent on your side too. Use stable traderInvoiceNumber / externalId values so retries don’t double-submit.
  • Surface failures. Show the failure reason and let the user retry after fixing the cause.