Publishing console
Where your APIs become products
The half of Wanda Portal your own team works in: a catalogue with versions and a lifecycle, bound to the resources the platform meters and prices.
- Versions and lifecycle
- One binding for pricing and enforcement
- The edge follows the catalogue
The catalogue
APIs as first-class objects
Not a folder of documents. An API has versions, each version has a state, and the platform knows which version a given consumer is entitled to call.
Versions that keep their word
A document is stored exactly as you published it and served with its checksum, so what a developer downloads is byte for byte what you shipped.
A lifecycle with rules
Draft, published, deprecated, retired. A transition table decides which moves are legal, and an illegal one is refused naming the moves that are not.
Resources the platform can meter
Bind paths and methods once. Pricing, quotas and enforcement all read that same binding, so the catalogue and the bill cannot describe different things.
Diff before you publish
See what changes between two versions, and what the change does to the edge, before anything moves.
An audited actor on every move
Who published, who deprecated, who retired, and when. The history is the record rather than a log somebody has to keep.
A version has a life, and the platform knows it
Your consumers see the state a version is in, so a deprecation is a banner in their portal rather than an email they missed.
Publishing an API
Four steps, and the fourth is the platform's rather than yours.
- 1Your team
Import the document
Bring the OpenAPI document for a version. It is stored exactly as published, so its checksum describes what you actually shipped.
- 2Your team
Bind the resources
Map the paths and methods the platform will meter and enforce, so pricing and enforcement read the same record.
- 3Your team
Publish, past the checklist
The document parses, the resources are bound, and at least one plan covers them. Publishing refuses until all three hold.
- 4The platform
The edge follows
The gateway configuration is rendered from the catalogue, with a diff that says what changes before it changes.
What publishing does to the edge
Configuration written from the catalogue
Publish a version and the gateway configuration is rendered from it, deterministically. There is no second place to update and no drift between what you sold and what the edge enforces.
Drift is an alert, not a surprise
A hand edit to the live configuration raises an alert rather than quietly diverging from the catalogue that generated it.
Unpublish removes the routes
Retiring a version takes its routes off the edge on the next render, and the diff says so before it happens.
Test mode from the same document
One URL serves both environments, discriminated by the credential, so a partner's sandbox exercises the same routes as production.
Roles and teams
Your team, and your tenants' teams, work in the console with the scope you allow rather than sharing one login.
Guides beside the reference
Publish written guides alongside the generated reference, so a developer's first call does not need a conversation.
Bring one API document.
We will publish it, bind its resources and show you the gateway configuration that comes out of the catalogue, with the diff that would have told you what changed.