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 two states 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 tally_status. It is one of four values: running (Tally is open — safe to sync), not_running (the connector is online but Tally is closed — tell the user to open Tally), reconnecting (a transient link loss, recovering) or unreachable (the connector is offline or the machine is asleep). The boolean tally_running is the shortcut for running.

How do I know the right company is loaded?

The same response carries company_status: company_linked (the correct company is loaded and bound — safe to sync), no_company_loaded (Tally is running but no company is open), company_unavailable (known but not currently reachable) or company_not_linked (the company isn’t bound to this connector). So you can distinguish "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 only push when tally_running and company_linked are both true; otherwise surface the state to your user and retry. The endpoint always answers 200 with a usable state — even an offline connector degrades to unreachable rather than 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