Scopes

Registration limits the scopes an application may request. A user’s authorization grant then bounds the capabilities for one actor. Registration alone grants no user authority. Request only the scopes you need; refresh cannot expand them.

Scope	Permits
`openid`	OIDC identity authorization and bearer userinfo; bind the canonical actor through `/api/session`.
`profile`	Profile claims in the identity flow. This does not permit profile mutations.
`offline_access`	Refresh capability for continued server-side authorization.
`read`	Authorized reads of posts, replies, feeds, relations, events and reconciliation.
`post:create`	Create a public post or reply.
`post:edit`	Edit your actor’s own post with its current revision.
`post:delete`	Delete your actor’s own post.
`follow:write`	Add or remove your actor’s follows.
`like:write`	Add or remove your actor’s likes.
`inbox:read`	Read your actor’s private notification inbox.
`inbox:write`	Mark your actor’s notification as read.
`block:read`	Read your actor’s network blocks; safety scope granted on request.
`block:write`	Add or remove your actor’s network blocks; safety scope granted on request.
`report:write`	Submit a confidential report about a post, actor or application; safety scope granted on request.

Starter default

Use this exact default set in your registration request and first authorization:

openid profile offline_access read post:create post:edit post:delete inbox:read inbox:write

The starter does not request follows, likes or safety scopes by default. Request follow:write or like:write separately if your product needs them. For block:read, block:write and report:write, include a justification explaining the safety experience you will provide. Safety scopes are granted on request, rather than included in the default registration. A capability_required refusal means the current grant lacks the required scope. Update registration if necessary, then obtain deliberate consent for a new grant. Do not silently broaden authority, reuse an old grant, or fall back to anonymous reads. Anonymous public reads currently need no scope. They may later require an application credential. Application-attributed reads through an application-only credential are a planned follow-up; the client credentials grant is not supported today.

Get started

Integration

Updates

Starter default

​Starter default

Starter default