The Warden API connects a creator's membership system to 3D Warden. Your backend tells Warden what each commercial member currently holds. Warden gives each member a public verification page, and uses the same records as context when it investigates listings of the creator's designs.
You keep your membership system, your billing and your source of truth. Warden holds a copy of the facts you choose to send, and you can replace that copy at any time by sending it again.
Who calls it
A server you run, holding an integration key. It is a server to server API: Warden sends no CORS headers, so a browser cannot call it from another origin, and a key must never reach a browser.
A key belongs to one organization and one provider name. The key decides both, so no request names an organization, and a key cannot reach anything outside its own provider's records.
How it works
An admin makes a key
Signed in, once, from Commercial. The key belongs to one organization and one provider name, and it is the only credential your server holds.
Your server sends what each member holds
Up to 500 records a request, idempotent on your own member id. A dry run first, if you want to see what would happen.
Warden gives each member a public page
A printed code resolves to whether the certificate is genuine and whether the membership is active now.
Warden reads the same records when it investigates
A seller who is one of your members is shown as one, beside what they are doing. It is context, never a clearance. Commercial verification says what Warden does with these records, and what it refuses to.
Building with AI
The whole API is described in one OpenAPI 3.1 document, served at a fixed address. Point a client generator, an editor or your own agent at it rather than at these pages, and it has every route, every field, every limit and every error code without reading a word of prose.
What Warden will not hold
A record has no field for an email address, a phone number, a street address, a tax id, a payment detail or a provider account id. If you send one on a record or its credential, Warden tells you which field it refused and stores nothing of that record. On an identity, only that identity is refused.
Before you start
You need three things:
A Warden organization for the creator, and an admin of it. The API is part of the Creator and Studio plans, so the organization needs one of them.
A stable id for each member in your own system, one that never changes and is never reused. If your member id changes when somebody changes payment provider, pick a different id. Warden keys everything on it.
A way to say, for each member, whether their membership is in force right now.
Then follow the quickstart.