An error response always carries a code and a sentence a person can read. The code tells your workflow what to do; the sentence tells you why. There are only three kinds of code.
Retry: it will work in a moment
The connection was offline, TallyPrime was busy, or a rate limit was hit. Nothing is wrong with the request. Wait, then send it again - and because every write carries a fingerprint, a retry cannot post a duplicate even if the first attempt half-succeeded.
- connection_offline
- tally_busy
- rate_limited
Fix, then retry: the request is wrong
A ledger that does not exist in this company, a date outside the financial year, an item with no stock group. TallyPrime would refuse these every time, so retrying is pointless. Fix the data in the workflow (or in TallyPrime) and send again.
- ledger_not_found
- item_not_found
- date_out_of_period
- validation_failed
Fetch a person: something needs a decision
The application's access was revoked, the company was never paired, the plan's limit for the month is reached. No retry and no data change will help; someone has to act in the dashboard.
- unauthorized
- connection_not_found
- plan_limit_reached
A workflow that heals itself
Retry the first kind with a short back-off, route the second to whoever owns the data, and route the third to whoever owns the account. Three branches, and nothing pages you for a network hiccup.
Carry on in the docs
The step-by-step version, with every field and every code.