Projects

A project is the isolation boundary everything else lives inside: consumers, devices, API keys, billing, and audit history are all scoped to exactly one project. Nothing crosses that boundary — a credential from one project cannot read another.

Creating and listing projects

The /platform/v1/projects family covers the lifecycle:

Once created, the project's UUID is what you send as X-Project-Id on every /platform/v1 call, and what your API keys are bound to.

Membership and roles

A project has human members, each with a role that gates what they can do:

• owner — full control, including deletion and ownership transfer
• admin — day-to-day management
• member — regular collaborator
• viewer — read-only

Billing capabilities are a second, independent axis (owner / billing_admin / billing_viewer) so finance access doesn't have to follow engineering access. Manage both under /platform/v1/projects/{project_id}/members — GET the member list, PATCH …/members/{user_id}/role to change a role, PATCH …/members/{user_id}/billing-scope to set the billing axis, and DELETE …/members/{user_id} to remove someone.

New people join by invite: create one with POST /platform/v1/projects/{project_id}/invites; the invitee accepts the tokenized link and lands in the project with the role the invite named.

The audit log

Every administrative action in a project — key mints and revocations, role changes, billing operations — is recorded and queryable at GET /platform/v1/projects/{project_id}/audit-log. Entries carry the actor, the subject, and before/after snapshots where they apply, so you can answer "who changed this, and when" without filing a ticket.

Reference

Full request/response shapes for every operation above are in the generated API reference under projects, members, and invites.