Developer portal
A developer portal your customers see as yours
The half of Wanda Portal your partners sign in to: your brand, your catalogue, your domain, and a consumer who reaches their own data and nothing else.
- Branded per tenant
- Served on your domain
- Sandbox from the first minute
What a consumer gets
Their keys, their usage, their statements
A developer signs in and sees their own record, keys, usage and statements. Sandbox keys and test mode are there from the first minute, so nothing has to be billed to be tried.
Your catalogue, browsable
They search your published APIs, read the reference for the version they are entitled to, and see a banner when a version they depend on is deprecated.
Headroom on every response
Rate limit and quota state ride on the response while a call is still succeeding, not only once it fails. A consumer can see the wall coming.
Spend as it accrues
A transaction log and a provisional figure that moves as calls land, so the bill is visible while it forms rather than arriving at month end.
Your brand, from six inputs
A tenant brands the portal without ever editing a theme file: 45 light and 35 dark tokens are derived server-side, and a preview returns byte-identical bytes to a save.
Legibility enforced at the write
A derived colour is searched until it clears 4.5 to 1 for text or 3.0 to 1 for fills. A palette that cannot get there is refused, naming the pair, the ratio and which input to change.
Your hostname, your login
Before sign-in the hostname resolves the tenant; after sign-in the authenticated principal decides. A forwarded host header is deliberately ignored, because a header a browser can set must not choose which brand it sees.
Statements in their language
Portal and statement documents both read from a translation catalogue, so an invoice arrives in the language it is filed in.
A billing contact on the account
Statements go to the address on the account rather than to whoever asked for them, with every attempt recorded.
Giving a partner a key
How a developer gets from an invitation to a billable call.
- 1Your team
Open the account
A consumer record for the partner, on the plan you agreed, with the roles their team needs.
- 2Your partner
Sign in and take a test key
They see your brand on your hostname, browse your catalogue and create their own sandbox key.
- 3Your partner
Build against test mode
Full fidelity, same decision path, same headers. Test usage travels the whole path and never reaches a statement.
- 4Your partner
Switch to a live key
The same portal issues it. From the first live call the usage meters, rates and appears on their statement.
What a consumer cannot get
A portal is a tenancy boundary before it is a user experience. This is where that boundary is drawn.
A closed allowlist, not a filter
The consumer principal can reach its own record, keys, usage and statements, and nothing else. The boundary is a list of what is permitted rather than a list of what is blocked.
Absent, not forbidden
A sibling consumer answers 404 rather than 403, so a developer cannot map the tenant by watching status codes change.
Probed adversarially
Thirteen path probes cover traversal, encoded and double-encoded separators, duplicate slashes, dot segments, semicolon parameters, case variants and cross-tenant addressing.
Roles and teams
Your customer adds colleagues to their own console with the scope you allow, rather than passing one login around an office.
See it wearing your colours.
Send us your palette and your logo and we will show you the portal branded as yours, including what our own contrast rule does if a colour cannot be read.