Limits & versioning

Rate limits, plan allowances, and how the API changes over time.

Rate limits

Each account may make a set number of requests a minute, shared by its applications and set by its plan (listed on the Pricing page). A limited response returns 429 with a Retry-After header in seconds.

TallyPrime does one thing at a time
TallyPrime handles one request at a time on the customer's computer. So requests to one connection run one after another. A hundred parallel requests to one connection will not finish sooner. Batch them, or space them out.

Plan allowances

Only a write counts: an entry TallyPrime saves. Reads — lookups, reports and dropdowns — are free, and so are failures and status checks. Past the allowance, writes return plan_limit_reached while reads keep working; nothing is charged automatically.

Times

Every timestamp is UTC, ISO 8601. The dashboard shows the same moments in your own zone.

Versioning

  • The version is in the path: /api/v1/…. v1 is the first Balancely API.

  • Within a version we only add — new fields on a response, new optional fields on a request, new operations. Parse defensively and ignore what you do not recognise.

  • A new version appears only for a change that would break an existing integration, and runs alongside the old one.

  • Connectors are versioned separately, so a connector release does not require reconnecting or re-entering credentials.

Deprecation

If we ever retire an operation, we will announce it and keep it working for a stated time. We also mark it in the operation catalogue at /api/v1/tally/operations. That is why a connector should read that list instead of hard-coding one.

Health endpoints

PathPurpose
/healthzIs Balancely up?
/readyzIs Balancely ready to take requests?

Neither requires authentication and neither exposes customer data. Also see Errors for how a temporary outage is reported to a running workflow.

Something missing on this page? Tell us and we will fix it.