Know if Tally is running before you sync.

Most Tally tools make you fire and pray: send the payload, and find out it didn’t land only when something downstream is missing. The Tally connector status API flips that around — one call tells you whether the connector is online, whether Tally is running, and whether the right company is loaded, so your app can decide before it sends.

It’s the same live truth the developer portal shows, exposed on the REST API as a health object and a list of checks you can branch on. Check → decide → push, instead of push → timeout → retry.

How do I know if the customer’s Tally is running?

Call GET /v1/companies/{id}/health and read health.tally.status: running (Tally is open), not_running (the connector is online but Tally is closed — tell the user to open Tally), unreachable (Tally is open but not answering — busy, or a dialog is waiting) or unknown. It is unknown whenever the connector itself is offline (health.connector.status): only the connector can see Tally, so the API does not guess. The last state it did see is in health.tally.last_known.

How do I know the right company is loaded?

The same response carries health.company.status: loaded (the linked company is open in Tally), not_loaded (Tally is running but this company is not open), paused (sync is paused for it) or not_linked (no connector is linked to this company yet). When it is not open, the company check says which case it is — TALLY_COMPANY_NOT_OPEN or WRONG_COMPANY_OPEN — so you can tell "Tally is closed" from "the wrong company is open" and show the right message.

Why does my Tally sync fail silently — and how do I stop it?

Silent failure happens when you push without knowing the connector’s state. The fix is a preflight check: call the health endpoint and read checks — one entry each for connector, tally, company and sync, with a status of pass, warn, fail or unknown. Push when connector, tally and company all pass; otherwise show the user the code of the first failing check (for example CONNECTOR_OFFLINE or TALLY_NOT_RUNNING) and retry. The endpoint always answers 200 with a usable state — an offline connector is an answer, not an error — and it’s unmetered, so you can call it before every sync.

How does this relate to connector_timeout?

They’re the before and after of the same fact. The health endpoint is the preflight — it tells you a push won’t land before you send it. A 504 connector_timeout on a data-plane call is the runtime signal when no connector answered. Transaction status is the outcome — whether Tally accepted what you sent. Check health first and the timeout becomes the exception, not the norm.

What the health check tells you