Thinking about building on SIDES
Write to [email protected]. Tell us what you build and who you build it for; you do not need a finished plan.
Contact
How to reach the SIDES crew
Partner enquiries, support for an existing integration, the state of the platform, and the statutory company details. Contact, support, status and the imprint all live on this page — that is where the site footer’s links point.
Contact
Partner enquiries
Write to us. SIDES LABS is a product of SIDES, operated by SimplyDelivery GmbH in Berlin, and its product mailboxes are at sideslabs.com. The company’s own statutory contact — postal address, telephone and e-mail — is in the imprint below.
Partner enquiries: [email protected]Support for an existing integration: [email protected]
Not sure which route fits?
Integration partner, service provider or agency — the contract is the same, the starting point is not.
Company details
SIDES and SIDES LABS are operated by SimplyDelivery GmbH in Berlin. The statutory company details are below.
Support
Help with an integration you already have
Write to [email protected]. A support area inside the partner portal, attached to the account that raised the request, is being built — until it is, that mailbox is the route.
What to include
Four things turn a support request into an answer instead of a conversation. Every one of them is in the response your client already received.
- The request id
-
Every response carries
X-SIDES-Request-Id, and it is the same value asrequest_idin an error body. It is how we find your exact call. - The error code
-
The stable
codefrom the Problem Details body — not the title and not the status on its own. - The endpoint and the time
-
Method, path and roughly when, in UTC. All of our timestamps are UTC and
end in
Z. - What you expected
- Especially for a permission problem: which scope you believed the client held, and what the token response actually granted.
Before you write
You got a 403 and expected a 200
Read the scope field of the token response rather than the
scope you requested. The granted scope is the intersection of what your
client holds and what you asked for, and asking for more is not an error.
You got a 401 after a token that worked
Access tokens are short-lived by design. A 403 with
ACCOUNT_INACTIVE is different: the token verifies, but the
client it names is no longer configured. Fetching a new token will not
help — that one needs us.
You got a 429
Honour Retry-After. Rate limits are configured per OAuth
client today, and will additionally follow the partner tier once tiers
exist. The X-RateLimit-* headers describe the daily budget;
the per-second burst control is enforced but not reported.
A rate-limit header is missing
Treat that as “not counted”, never as “nothing left”. The headers are absent on the health probes, for a principal with no daily limit, and when the counter could not be read.
System status
Is the platform up?
The API answers two probes, both public and both deliberately unmetered —
a probe that can be rate limited turns a limit into an outage.
/health says the service is running; /health/ready
says whether it can actually serve, and names the failing dependency when it
cannot.
A readiness probe is read by operators, so it names the dependency in every environment. It never names a host or a credential.
There is no public status page yet
Until there is, the probes below are the honest answer, and an incident that affects partners is communicated directly to them.
GET
/health/ready
200 { "status": "ready",
"checks": { "database": "ok",
"signing_key": "ok" } }
503 { "status": "unready",
"checks": { "database": "unreachable",
"signing_key": "ok" } }Imprint
Legal information
The statutory imprint under §5 DDG — registered office, managing directors, register entry, VAT identification number and contact — is the versioned document at Imprint.
Why this anchor is a link rather than the details themselves
This page carried a copy of those details for two phases, because
legal/imprint.html did not exist yet and §5 DDG says
“permanently available”, not “from phase 7”. It was
recorded as a debt at the time, and the debt is paid: the versioned document is
the authority now, and this page points at it instead of holding a second copy.
Legal text kept in two places drifts, and the copy a consent record points at
is the one that has to be right.
Privacy
What we do with data, in short
The privacy policy is the binding document. These three decisions shape everything in it, and they are worth knowing before you read it.
- No external resource loading
- Fonts, images, icons and scripts are served from this origin. No CDN, no font host, no analytics beacon, no embedded map — on any page. An IP address is personal data, and a third-party request discloses one.
- Consent is recorded with its version
- Every consent is stored with the version of the document it was given against and the moment it was given, so “what did they agree to” has an answer.
- Deletion is anonymisation
- A departing person disappears from the data while the audit trail and the published marketplace history survive. That is a deliberate design decision, not a limitation.
The full privacy policy is the binding document, and these three decisions did not change in it.
Ready when you are
Registration creates your business partner, your first administrator and your tier. Publishing anything is a separate, recorded step.
