> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sync2books.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tracking Results (the async model)

> Most eTIMS operations don't finish inside your HTTP request. They are accepted, processed, and the KRA result is confirmed shortly after. Understanding this...

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

| Operation                           | Mode        | Returns               |
| ----------------------------------- | ----------- | --------------------- |
| Connecting a company (advanced API) | synchronous | the connection result |
| Catalog register / sync             | async       | `{ syncBatchId }`     |
| Sales / credit notes                | async       | `{ syncBatchId }`     |
| Stock adjust / transfer             | async       | `{ syncBatchId }`     |
| GET reads (catalog, sales)          | synchronous | the data              |

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:

```
status: pending ──▶ syncing ──▶ synced     (result available)
                            └──▶ failed     (error message available)
```

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:

```bash theme={null}
# Did my sale get accepted?
curl -X GET "https://api.sync2books.com/companies/{companyId}/integrations/etims/sales" \
  -H "X-API-Key: {apiKey}"
# look for the sale marked accepted, with a KRA receipt number (ETR-…)

# Is my item registered?
curl -X GET "https://api.sync2books.com/companies/{companyId}/integrations/etims/catalog/items" \
  -H "X-API-Key: {apiKey}"
# look for the item's status = Registered
```

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.

<img src="https://mintcdn.com/syn22books/Q_zUldTvHn0TTT5T/images/etims/07-sync-monitoring.png?fit=max&auto=format&n=Q_zUldTvHn0TTT5T&q=85&s=70764d7d497ee30e8e3a59c5a515e9ec" alt="Sync monitoring — batches, items, and errors" width="2880" height="1800" data-path="images/etims/07-sync-monitoring.png" />

## 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.

## Read next

* [Sales & Credit Notes](/etims-sales) — what "accepted" looks like
* [API Reference](/etims-api-reference) — every endpoint and field