What a POS partner programme gates, and what it does not
In short
A POS partner programme controls 3 things: which permission scopes you may request, whether you get production credentials, and whether you appear in the platform's marketplace. It does not control your architecture, your data model, or whether a restaurant may authorise you — and knowing which side of that line a blocker sits on stops a project stalling on the wrong thing.
Key takeaways
- The programme gates scopes, production credentials and marketplace listing — 3 commercial decisions, not technical ones.
- Order write, catalogue write and anything touching payment objects are the capabilities most often gated behind review.
- Access is also a contract question: the merchant's plan tier can withhold an API the partner programme would happily grant.
- Approval runs on somebody else's timetable, so sequence the build so that waiting blocks the least valuable work.
A POS partner programme is a commercial gate wearing technical clothing. It decides which permission scopes your application may request, whether you are issued credentials that work against real restaurants, and whether you are listed in the platform's marketplace where operators go shopping for connectors. Everything else people blame on it — data models, rate limits, what the API can express — was already true before you applied.
Toast, Square, Clover, Lightspeed, PAR Brink and Petpooja all run some version of this model, and being clear about the line matters because the 2 kinds of blocker have completely different responses. A technical blocker is work. A commercial blocker is a queue, and no amount of engineering shortens it.
The rungs most platforms use, and who decides each one
| Rung | What it unlocks | Who decides |
|---|---|---|
| Public documentation | Enough to design the integration and estimate it honestly | Nobody. Read it before scoping anything |
| Developer account | Keys against a test environment and a sandbox merchant to build against | Usually automatic on signup |
| Scope grant | Permission to request the specific capabilities your build needs | The platform, on review, on its own timetable |
| Production credentials | The ability to act against a live restaurant that has authorised you | The platform, often after a technical review |
| Marketplace listing | Discovery by operators who never heard of you | The platform, on commercial criteria including support and volume |
The 2 rungs that produce most of the surprise are scope grant and production credentials, because a team that has built happily against a sandbox for 6 weeks discovers that the sandbox never enforced the thing that is now blocking them. The full sequence, including which steps are work and which are waiting, is laid out in from a developer account to a live restaurant.
Which capabilities usually need review, and which usually do not
- Commonly gated: writing orders into the till, writing to the catalogue, anything touching payment or tender objects, and bulk access to another merchant's data. A bug in any of the 4 becomes a wrong charge or a lost service, so platforms review them.
- Commonly ungated: reading a merchant's own catalogue and reading their own sales reporting, once that merchant has authorised you. This is enough to build menu display, analytics, a reconciliation tool and most back-office work.
- Sometimes neither: event delivery. Some platforms treat callbacks as ordinary, others tie them to the same review as writes, and it is worth asking early because so much of the design depends on it — the POS fired the event and nothing moved explains why a system built on events alone needs a reconciliation sweep regardless.
- Verify per platform, not from a summary like this one. Capability names, tiers and review criteria change; the only reliable sources are the platform's current developer documentation and its partner terms.
The practical consequence for sequencing: read paths are usually available long before write paths, so the catalogue work can be finished, tested and demonstrated while the order-write review is outstanding. That is real progress rather than filler, because catalogue sync is the part that fails on scale rather than on permission — see the full catalog sync never finishes.
Four things the programme has no say in
- Your own data model, including the identity map between your catalogue and the till's — external IDs and the mapping table nobody designs until it breaks is entirely your problem and entirely within your control.
- How the restaurant's own configuration behaves. Prep-station routing, revenue centres and device groups are set in the store, which is why an order can land in the POS and nothing prints even with every approval in place.
- Whether the merchant's plan tier exposes the API at all. Some platforms sell integration access as part of a higher tier or an add-on, and that is a contract between the operator and the vendor that no partner status overrides.
- Who owns the credentials once they exist. That is a decision the operator should make deliberately rather than inherit from whoever wrote the code first.
What to build while an approval is outstanding
The sequencing question is which work is genuinely blocked. Menu modelling, the ordering front end, the identity map, reconciliation reporting and the operator-facing admin are all buildable without a single write scope — the sort of unglamorous internal tools and ops work that determines whether the finished integration is supportable.
There is also value that never touches the POS at all. Host-stand and waitlist tooling is a good example: quoting a wait accurately is its own engineering problem, worked through in quoted twenty, seated in fifty, and it ships while the order-write review sits in a queue. What the review itself will ask you to demonstrate is a separate preparation exercise, covered in what a POS certification review asks you to show.
Engineering estimates are ours to make. Approval timelines belong to a company that has never met your project, and treating the second like the first is how a launch date becomes fiction.
Ask which rung you are on before anybody estimates, and plan the build so a queue blocks the least valuable work. The rest of this silo sits under integrating with the POS on the counter, inside our restaurants and food service practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Do you have to be an approved partner to integrate with a restaurant POS?
Not for everything. Most platforms let a developer account read a merchant's own catalogue and reporting once that merchant authorises the connection, which is enough for menu display, analytics and reconciliation work. Writing orders or catalogue changes into the till is the part that typically needs a scope grant and production credentials, and those are reviewed decisions rather than automatic ones.
How long does POS partner approval take?
Nobody outside the platform can tell you, and any supplier who quotes a date is guessing. It is a review queue run on the platform's schedule, affected by how complete your submission is and by how busy they are. The right response is not a better estimate but a build sequence in which the approval blocks as little as possible.
Can a restaurant's plan block an integration even after partner approval?
Yes, and this is the blocker teams miss most often. Access to a POS API is frequently tied to a plan tier or a paid add-on in the merchant's own contract, so an approved application can still be unable to act for a specific restaurant. Confirm what the operator's plan and contract actually include before scoping, not after.
Does being listed in a POS marketplace change what the integration can do?
Usually not technically — a listing is a distribution decision rather than a capability one. It affects discovery, install flow and sometimes the support commitments you take on. The capabilities themselves come from the scopes granted to your application, which is why listing is worth treating as a commercial project separate from getting the integration working.
- pos
- partner programme
- integration
- restaurants
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- External IDs: the mapping table nobody designs until it breaksThe identity map between your catalogue and the till is the contract that makes every order possible, and 4 routine events break it silently. Design it as a versioned artefact.definition
- It works at the first location and returns an auth error at the other fourIdentical code, one store working and four rejecting, means authorisation was granted per merchant location and only completed once. The fix is an inventory, not a retry.diagnostic
- Order source and dining option: two fields your reporting rests onTwo small POS fields decide whether an injected order is taxed, routed and attributed correctly — and a wrong value is invisible until the first report nobody can answer.definition
- The full menu sync hits the limit before it finishesA sync that works on a 40-item menu and dies on a 400-item one is not too big. It is making one request per item, at the same minute as every other location.diagnostic
- The order lands in the POS and nothing prints at the stationThe POS accepted your order and the line never saw it. Routing is configuration — dining option, revenue centre, station map — and no field in your payload can override it.diagnostic
- The POS says it sent the event and your system never movedA status event that arrives after service is worth nothing. Five places it dies before your handler, and why the durable fix is a polling sweep over open orders rather than better webhook code.diagnostic
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