Security and hosting

Every request reaches exactly one workspace, and the credential decides which it may be. An integration gets its own key bound to one role:

curl -X POST https://api.standards.new/v1/api-keys \
  -H "Authorization: Bearer stndrds_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{ "name": "status-page", "roleId": "role-uuid", "expiresAt": "2027-01-01T00:00:00Z" }'

That key holds the role and nothing else. You can bind a role only when your own permissions cover everything it grants; otherwise the API answers 403. The secret is returned once, in this response.

One workspace per credential

The key names its workspace, so a request needs no tenant parameter. A request that names another workspace in its tenant header is refused; the header only confirms the key's workspace. Every record row carries its workspace id, and the API scopes each record query to the credential's workspace.

Inside a workspace, a record you may not see answers 404:

{
  "success": false,
  "statusCode": 404,
  "message": "Record \"abc123\" not found.",
  "code": "SCHEMA_RECORD_NOT_FOUND"
}

A caller cannot tell a private record from a missing id.

Roles decide each action

A role grants actions (read, create, update, delete, and manage for permanent deletion) per object, and per platform resource such as the schema, API keys or people. Every workspace starts with owner and member, which cannot be edited. To give someone less than member, build a custom role and assign it instead. Nobody grants what they do not hold: editing a role, assigning one and inviting someone all check it. Live updates follow the same permissions as the API. Roles and permissions lists the full catalog.

Private records and sharing

A record, an agent or a routine is visible to the whole workspace, or private to its owner. Its owner, or a member who can edit it, shares a private record with named members as Can view or Can edit. The object's permissions stay the ceiling: a share never grants an action the member's role forbids on that object. See Sharing.

What keys and agents may do

• A personal key does only what both its role and its owner's current roles allow, read again on every request. Demote the owner and the key narrows on its next call. Suspend them and it is refused.
• A workspace key acts with its own role, which its creator could only pick within their own access.
• An agent acts with its own role intersected with the roles of the person it works for: whoever sent the message, ran the routine, or last turned on or edited the trigger or schedule that started it. A tool call outside that person's access is refused to the agent, which reads the refusal and carries on.
• An MCP client gets up to eight tools, narrowed to what its key, or the person who signed in, may do.

One limit to know: after a sign-out, an access token already issued stays valid until it expires, about one hour. A dedicated instance can check each token with the auth server instead, which cuts that window to 30 seconds.

Where Standards runs

The shared host is api.standards.new. A dedicated instance runs the same API on isolated servers reserved for your organisation, under your hostname, for data residency, an audit that requires isolation from other tenants, or a workload you want sized on its own.

Meeting recordings are processed in the EU by our recording vendor, which deletes them after 24 hours. Mail bodies, history included, are sent to the embedding provider for meaning-based mail search, through the Vercel AI Gateway; ai.embeddings.emails: false turns it off. Cloud browsers run at our browser provider, which gives no data-residency guarantee, even in its EU region.

A licence lets your team run Standards on its own infrastructure. You have a licence? Read the licensed documentation.

Next steps

• Workspaces and API keys: create, scope, detach and revoke keys.
• Roles and permissions: the catalog of capabilities and the object grant.
• Dedicated instances: what changes when the API runs under your hostname.
• Book a demo