COMPANY · PARTNERS · APPLY
No form. Because we could not act on what it collected.
An application gets a reference number and enters a review queue. A reviewer reads it and may ask questions before moving it to a sandbox. What follows — certification, an operator's go-live grant, your own API keys — is named below, in order. Nothing on this page collects anything: no form, no input, no address kept anywhere.
A form here would collect what this build cannot act on.
This build does not wire an intake route of its own. Collecting a reference or an email address and having nowhere to send it would be worse than not asking. So this page describes the process rather than imitating it.
What happens, in order.
- Applied. The application gets a reference number and sits in the review queue. Nothing is provisioned yet.
- Reviewing. A reviewer reads it and may come back with questions.
- Sandbox. A demonstration organization is provisioned so the integration can be built and tested.
- Certifying. The real exercises run against the integration and the evidence is recorded.
- Live. An operator attaches a grant to the organization at go-live — no public form provisions one.
- Keys. A contact holding the Admin role signs in with a code sent to the email on the approved application, then mints, rotates and revokes API keys within that grant.
Why a code, not a password.
There is no self-service signup and no password to set or steal. A partner contact signs in with a one-time code sent to the contact email on the approved application. Minting, rotating and revoking a key is limited to contacts holding the Admin role, checked again on the server rather than only hidden in a screen.
Before you go any further.
Everything above describes a process. It does not describe this build. Nothing on this page submits, stores, or emails anything.
This build's register carries no row for application intake, sandbox provisioning or self-service keys. Named below rather than dropped, because a page that quietly shortens its own slice is the same defect as a claim with no receipt.
The register holds 17 live · 2 partial · 2 planned · 5 not yet.
3 of the 3 capabilities this page depends on have no row in the register yet, so this page will not print a state for them. They are named rather than dropped, because a slice that silently shortens itself is the same defect as a claim with no receipt.
- partner-application-intake
- partner-sandbox-provisioning
- partner-self-service-keys
The register route serves, but it carries no row for these yet. List what it does carry:
curl -s https://id.orbis.id/api/site/register | jq -r '.entries[].slug'Straight answers.
- Can I submit an application on this page?
- No. There is no form here. Read what happens above, then see below where to go.
- Do I need a password?
- No. A one-time code sent to the contact email on the application replaces one.
- Who can mint API keys?
- A contact holding the Admin role on the approved application, after an operator attaches the grant at go-live. No public page mints or displays a key.
- Is there someone I can talk to instead?
- See the contact page. It names the same constraint this page does and points at what is possible today.
Apply, here and now
The form below posts to the live intake — POST /api/partners/applications
on the cell that serves this page. You get an application id back; keep it, it is how
you check status. Ten applications per address per hour; the eleventh answers 429.
Collecting a reference and an email with nowhere to send them would be worse than not asking. Every SaaS company in the world has shipped the form anyway, because a form looks like traction. We would rather look smaller and be usable.
Do not trust us. Check us.