Restaurants and outlets
Single sites and chains, taking orders across counter, phone, webshop and delivery platforms, all landing in one system.
The ecosystem
SIDES is the platform behind the counter: orders, outlets, kitchens, webshops, delivery, payment. The partner ecosystem is everything built around it by companies that are not us — and SIDES LABS is where that work happens.
What it is
A business partner is a software company registered with SIDES LABS. It builds a service against the SIDES API, submits it for review, and — once approved — lists it in the SIDES marketplace, where hospitality operators find it from inside the product they already use.
That is the whole loop, and every part of it is a first-class feature of the platform rather than an arrangement negotiated per partner: the tiers, the developer resources, the API changelog, the submission and approval workflow, the ratings, and the usage statistics that tell you how the integration is actually doing.
The route
Five steps. The order matters, because nothing becomes visible to a SIDES customer without an explicit, recorded transition.
Company, first administrator, tier, and the consents that go with them. The partner starts unverified and is not publicly visible until it is confirmed.
Server-to-server integrations authenticate as OAuth 2.0 clients and get a short-lived access token. That is the plane that exists today. Partner users will sign in for the same kind of token, checked by the same middleware.
Scopes are hierarchical, nested by domain, and read-only unless they end in
:write. What you were granted is in the token response — read it
rather than assuming your request.
Listing text, screenshots, categories and the version itself go in together. SIDES reviews the submission; approval and rejection are both recorded.
The approved listing appears in the marketplace. Usage statistics, ratings and reviews come back to you in the partner area of the portal.
The other side
Not developers. Operators — the people running the business while your software runs underneath it.
Single sites and chains, taking orders across counter, phone, webshop and delivery platforms, all landing in one system.
Preparation, routing and dispatch, where a two-minute delay is a real cost and a failed integration is a visible one.
Franchise and multi-site management: reporting, pricing, menus and rollouts across every location at once.
What you can rely on
code your client branches on and a request id you can quote.
Honest status
Today the API authenticates OAuth machine clients and answers
GET /v1/system/me with the identity, scopes and rate limit of the
calling principal. Partner registration and sign-in, the marketplace catalogue,
the changelog and the tier pages follow in the phases after it. This page
describes the platform being built, and says so rather than implying more.
Not yet through this site. Self-service registration arrives with the registration flow; machine-client credentials are issued by SIDES directly until then. The contact page says how to ask.
From an OpenAPI specification that is written before the handlers and served at
/api/docs. The service refuses to start if its route table and the
specification disagree, so the documentation cannot quietly drift from the code.
Yes, per OAuth client and per partner tier. Responses carry
X-RateLimit-Limit, X-RateLimit-Remaining and
X-RateLimit-Reset for the daily budget, and a
429 carries Retry-After. Treat a missing header as
"not counted", never as an exhausted budget.
Integration partner, service provider or agency — the contract is the same, the starting point is not.