Security

How connections, credentials and your accounting data are protected.

Last updated 1 September 2026
Where your accounting data lives

Your books stay in TallyPrime on your own computer. This service does not hold a copy of them.

An entry passes through us on its way into TallyPrime, and the saved record is read back to confirm it landed. TallyPrime’s reply is kept for 48 hours so a repeated request is answered without posting twice, then deleted.

We record that an operation happened — which action, whether it succeeded, how long it took, and a short summary such as the voucher number, party and amount — so you can see your own activity and we can meter usage. It is kept for your plan’s history period.

When an entry made in Accounts (typed in or imported) is waiting to be sent or has failed, its details are kept so you can fix and resend it. They are deleted as soon as the entry is saved, and a failed entry’s details are deleted after 14 days.

How the connector reaches TallyPrime

The connector makes an outbound connection from your computer to this service, the same way a browser reaches a website. Nothing on your network is exposed to the internet.

No port forwarding, no static IP, no inbound firewall rule and no VPN is required.

The connector only ever talks to TallyPrime on the same computer, and only when an automation you built asks it to.

It contains no accounting logic. Every rule runs on our servers, which is why it rarely needs updating.

Credentials

The connector's credential is sealed with Windows DPAPI — readable only by your Windows account on that machine. Copying the file to another computer yields nothing usable.

Connection credentials are encrypted at rest with AES-256-GCM, which detects tampering rather than decrypting altered data.

Client secrets are stored only as a hash and shown exactly once, at the moment they are created. There is no way to retrieve one later — rotate instead.

Passwords are hashed with bcrypt. Access and refresh tokens are stored only as hashes.

Passwords, secrets, tokens and authorization codes are redacted before anything is written to a log.

Access control

Every application declares which permissions it needs, and you approve them per connection on a screen that names both.

Disconnecting a connection immediately stops every token that depended on it.

Deleting an application revokes every credential it ever issued.

An authorization code that is presented twice invalidates the whole authorization, because a replayed code means it leaked.

Operational

Sign-in, secret rotation, connection changes and revocations are recorded in an audit log you can read in your dashboard.

Sign-in, pairing and token endpoints are rate limited, and repeated failed sign-ins lock an account temporarily.

Staging and production run on completely separate databases, secrets and credentials. Neither can reach the other.