Gated endpoints: the ledger APIs you cannot call until your app is reviewed
In short
A gated endpoint is a ledger API capability you cannot call until the platform reviews your application. Access runs in 4 tiers: sandbox, a private connection to tenants you already control, a published app under review, and endpoints released only under a signed partner agreement. Payroll, bank feeds and filing sit in the fourth.
Key takeaways
- Sandbox access tells you the shape of a payload, not whether you may call it in production.
- Tier 2 — a private connection to the firm's own tenants — covers more real work than most scopes assume.
- Payroll, bank feed submission and filing are the 3 families most often held behind an agreement.
- Check the access tier per endpoint before scoping, not per platform. Access is granted at capability level.
- The honest fallbacks are file exchange and an operator-driven export, both cheaper than a stalled build.
A gated endpoint is one you can read about in the documentation, exercise in a sandbox, and still not be permitted to call against a live company file. Ledger and practice platforms grant access in tiers, decided per capability rather than per developer. Discovering that after a build has been scoped around a write you cannot make is an expensive way to learn how these programmes work.
The documentation rarely says so plainly, because it describes the API surface rather than your entitlement to it.
The four tiers of access
| Tier | What you can do | What it takes | What it does not prove |
|---|---|---|---|
| 1. Sandbox | Call everything against a demo company | A developer account, minutes | Nothing about production entitlement |
| 2. Private connection | Connect to company files you or the firm already control | Often a paid developer tier, self-service | That anyone else can install it |
| 3. Published app | Any firm can install it from the platform's marketplace | Security questionnaire, functional review, support and branding rules, weeks of round trips | That restricted endpoints are included |
| 4. Agreement-gated | Call the restricted capability families | A signed agreement, commercial qualification, a business case | Availability — some programmes are closed to new entrants |
The distinction that matters most is between tiers 2 and 3. If the software is for the firm's own use across its own client files, tier 2 is often sufficient and skips the review cycle entirely. Tier 3 is for software other firms install, which is a product decision rather than an integration one.
The capability families that sit at the top tier
- Payroll. Writing payroll data is restricted on most platforms: statutory filing consequences, plus personal data the platform will not let a third party mishandle.
- Bank feeds. Submitting transactions as a bank feed — rather than importing ordinary transactions — is supervised almost everywhere, under a separate agreement.
- Tax filing and statutory submissions. Anything filing to a revenue authority through the platform is gated, often not exposed to third parties at all.
- Bulk and batch operations. High-volume endpoints are reserved, because misuse at volume is hard to undo across hundreds of client files.
- Cross-tenant administration. Enumerating or provisioning the client files under a practice account is partner-tier, not ordinary.
Gated is not the same as rejected
Three failures produce the same unhelpful error, and separating them is the first debugging step. Access gating is an entitlement problem. Scope gating is an OAuth 2.0 problem — the token was issued without the scope, and re-consent fixes it. Business-rule refusal is neither: the call was permitted and the ledger declined it, as when a posting is rejected because the period is closed.
A fourth case looks like gating and is not: the endpoint exists, you may call it, and it does not model what you need. The classic is payment allocation, where the write succeeds and supplier bills stay open because the payment was never linked to them. No partner status fixes a data model.
How to check before scoping
- List the writes, not the features. Every feature reduces to create, update and delete calls on named objects. Write them down first.
- Find each in the reference and record its stated access requirement verbatim, including any note about a programme or agreement.
- Try each write once in a sandbox and once against a real file you control. Sandbox success alone means nothing.
- For anything gated, ask the platform in writing what the qualification and timeline are before the estimate is issued, and treat silence as a no.
- Price the fallback for every gated write — file exchange, operator-triggered export, delayed sync — and put it in the plan as the default, not the contingency.
Read access has its own version of this. Where a platform offers no change or event feed, a mirror must poll, and polling is what causes a sync to miss back-dated edits. Where reporting endpoints are limited you rebuild the numbers from transaction detail — which is what happens when a firm wants flux analysis with thresholds that make it useful and the report API will not return that shape.
Keep the gated capability as one replaceable component. A build that cannot function without someone else's approval has a single point of failure you do not control.
That is the discipline: know the tier of every write before committing to it, and keep the gated ones behind an interface. The ledger and practice-stack integrations topic covers what happens once access exists, and the software we build for accounting and tax practices is mostly the layer above — work scoped under internal tools and operations software.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Can we use a firm's own login instead of applying for API access?
You can use the firm's own credentials to authorise an application against its own client files, which is tier 2 and legitimate. What you should not do is drive the web interface with a script under someone's login: it breaks on every interface change, usually violates the terms of service, and attributes machine actions to a named person in the audit trail.
How long does a published app review take?
Plan for weeks rather than days, and at least one round of follow-up questions. The variable part is rarely the functional review — it is the security questionnaire and the evidence asked for about data handling. Build so the app is useful at tier 2 while review is outstanding, rather than treating approval as a launch dependency.
What if the endpoint we need is closed to new applicants?
Design around it, and be honest in the scope that you are doing so. The substitutes are a file exchange in the platform's own import format, an operator-triggered export on a schedule, or a delayed sync that batches work into an approved endpoint. Each costs latency or manual effort, and each beats a build blocked on an approval that is not coming.
Does holding partner status remove rate limits?
Not usually — throttling and entitlement are separate controls. A partner agreement changes which endpoints you may call; the request budget per minute and per day is a property of the app or the connected file. Design for retries and backoff regardless of tier, because a nightly job across hundreds of client files meets a limit whatever your status.
- ledger integrations
- API access
- scoping
- practice stack
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- A bookkeeping pilot passed, then the team went back to the spreadsheetQuiet abandonment after a successful trial is almost never a training problem. It is a placement problem, and there is a usage measurement that tells you which of four causes you have.diagnostic
- Professional clearance: the letter, and the records that have to moveThe clearance letter asks one question and takes 10 minutes. The data handover behind it decides whether the incoming firm can open a period, and it is where a change of accountant actually fails.definition
- The prepared-by-client list is a data structure, not a spreadsheetPBC stands for prepared by client. The useful definition is structural: a list of request items, each carrying nine fields, one of which is a state machine.definition
- What a client due-diligence record has to contain before work startsDue diligence is usually written about as a compliance narrative. The deliverable is a record: 10 fields, each with evidence attached, a refresh clock and a named approver.definition
Related across the site
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation