How it fits together
The four things this service is made of, and what happens when a workflow runs.
The pieces
Application
Lives in: Your automation platformThe identity a platform authenticates as: Client ID, Client Secret, redirect URLs, the permissions it may request.
Authorization
Lives in: Our serversOne application allowed to use one connection with a set of permissions. Revoking it stops that application at once.
Connection
Lives in: Our serversOne TallyPrime company on one computer you have paired. This is what an operation actually runs against.
Connector
Lives in: The computer running TallyThe small Windows app that carries requests to TallyPrime and nothing else.
Applications and connections are separate on purpose
What happens when a workflow runs
Your platform calls us
It sends the step data to our API with its access token.
We work out who is calling
The token resolves to one application, one connection and a set of permissions.
We check before we write
Ledgers, stock items, godowns and bill references are confirmed to exist in your company, and the entry is checked to balance.
We build the entry
The request becomes a properly formed TallyPrime voucher — the part that is genuinely difficult, and the reason this service exists.
The connector delivers it
It travels down the connection the connector already holds open, and is handed to TallyPrime.
We confirm it landed
TallyPrime reports success even when it recorded nothing, so we read the saved record back. Your response is built from that read.
Why nothing has to be opened on your network
The connector makes an outbound connection to us and holds it open — like a browser, or a chat app waiting for messages. Requests travel down that connection. No port forwarding, no static IP, no firewall rule, no VPN.
What makes an automated entry safe
Every write is verified
TallyPrime says “success” even when it saved nothing. So after every write we read the record back, and your response is built from what was actually saved.
A retry never doubles an invoice
Platforms re-send a step after a network hiccup. Each write carries a fingerprint, so a repeat updates the same record instead of creating a second one. Send an Idempotency-Key header to control it yourself.
Checks happen before anything is written
Every ledger, item, godown and bill named in a request is confirmed to exist first — so you get “the ledger X does not exist”, not a bare rejection.
Permissions
| Scope | What it allows |
|---|---|
tally.read | Read ledgers, stock items, outstanding bills and transactions from the connected company. |
tally.write | Create invoices, payments, notes, journals and ledgers in the connected company. |
connection.read | See which company and computer this connection points at. |
The person approving an application sees exactly these sentences. Anything outside them is refused with forbidden.
Something missing on this page? Tell us and we will fix it.