Base address
https://3dwarden.comEvery path in this reference starts with /api/v1/integration/. Requests and responses are JSON,
and a request with a body sends Content-Type: application/json.
Authentication
Authorization: Bearer wik_<64 hexadecimal characters>An integration key and nothing else. Write the scheme as Bearer, as shown,
and the key exactly as it was issued. The key decides the organization and the provider, so no
request names either. A person's session token is refused here with invalid_key, and a key opens
none of the app's own routes.
A missing, malformed, unknown or revoked key is one answer: 401 with invalid_key. Warden does not
say which.
Server to server
Warden sends no CORS headers, so a browser cannot call this API from another origin. That is on purpose. A key can write every member your provider holds, and it belongs on a server.
Endpoints
POST /api/v1/integration/entitlements | Sync entitlements |
GET /api/v1/integration/entitlements | List entitlements |
GET /api/v1/integration/entitlements/{external_id} | Get an entitlement |
DELETE /api/v1/integration/entitlements/{external_id} | Erase an entitlement |
POST /api/v1/integration/enrollments | Create an enrollment invitation |
POST /api/v1/integration/shop-status | Send shop registration deadlines |
Making and revoking a key is done by a signed-in admin and is described in Make a key.
Names, dates and ids
On the integration routes, fields are snake_case, in requests and in responses.
Dates are ISO 8601. Warden stores an instant and answers in UTC with an offset, such as
2026-09-21T18:04:11.123456+00:00. The number of decimal places varies, and a date that
shop-status reads back from your request comes back in the form 2026-10-23T00:00:00.000Z. Parse a
date with any ISO 8601 parser, and never compare dates as strings.
| Id | Shape | |
|---|---|---|
external_id | Yours, up to 200 characters | The stable id of a member in your system. Warden keys everything on it. |
public_id | 22 characters of A-Z a-z 0-9 _ - | Minted once by Warden for a record with a credential. Never changes while Warden holds the record. Safe to print. |
| Integration key | wik_ and 64 hexadecimal characters | A secret. Shown once. |
| Enrollment token | wen_ and 64 hexadecimal characters | A secret. Shown once, as token and inside enroll_url. |
| Cursor | Opaque | Only for finishing the walk that returned it. |
Dry runs
A sync, an erase and a shop-status request each take ?dry_run=1, which checks the request and
stores nothing. true is read the same way. Leave dry_run out, or send 0 or false, for a real
request. Any other value is refused with 400 invalid_request, and nothing is written or erased.
On shop-status, a key without the shop_status scope is answered 403 before that.
What Warden promises about change
The request shape is closed. An unknown field is refused by name, on the body, on a record, on a credential and on an identity, so a field you send is either one Warden reads or one it tells you about.
An error code is never renamed and never given a different meaning. New codes may be added, so
treat one you do not know by its HTTP status. The sentence in error can be reworded at any time.
New fields may be added to a response. Ignore a field you do not know.
What the records are for
Every record you send is read two ways. Its credential gives the member a public page. And when Warden investigates a listing of the creator's designs, it compares the seller against these records, and where it finds a match it says what that customer is entitled to and whether it was in force. A seller it cannot match is never reported as unauthorized. Commercial verification has the whole of it.
Not available yet
Webhooks from Warden to your system.
A read of only what changed since a given time.
Reading back the identities your members added through an invitation.
A self-serve test organization.
Proof of storefront ownership.
Catalog or time limited scopes on an entitlement.
Certificate files.