Skip to content
Manybases
esc

Search pages and sections. Try a tool name, an error code, a route.

↑↓ navigate↵ openesc close
  1. API reference
  2. Management plane
  3. Project users
Docs

API reference · Management plane

Project users

List the end users of a project's app, delete one, or hand a person a password-reset link.

Host: https://api.manybases.com · Key: ak_. Two gestures also require a signed-in human (X-Account-Session).

GET/v1/projects/:pid/users
Toollist_users
Effect200 { data: [{ id, email, created_at, last_seen_at }], cursor: null }. Never a password. Paginated: limit defaults to 50, maximum 200, and cursor reads the next page, oldest sign-up first
DELETE/v1/projects/:pid/users/:uid
Tooldelete_user
EffectDeletes the user and applies the cascade. Requires a signed-in human and confirms in two steps
POST/v1/projects/:pid/users/:uid/reset-password
Toolreset_password
Effect201 { data: { user_id, reset_url, expires_in } } — a link, returned to the caller, never sent. Requires a signed-in human and confirms in two steps

POST /v1/projects/:pid/invites and its invite_user tool were removed on 2026-09-22: the route answers 404 unknown_route. An invitation is issued from the app, by a person signed in to it — POST /v1/invites, see Auth.

last_seen_at is the date of the person's last living or refreshed session, or null when no session carries their trace any more — including someone who signed up and never signed in. It is not "the last request".

Deleting a user#

The property: nobody destroys a person and their data without being there and having seen what it destroys.

  1. X-Account-Session is required. The consequence falls on an end user who is neither the caller nor the account owner and cannot confirm; the responsible human is the account owner. Without the session: 401, no token, definitive.
  2. First call → 428 confirmation_required with will_destroy, a readable summary: rows destroyed, rows kept and frozen, memberships removed, files destroyed. Nothing has happened yet. Second call, same route plus confirmation_token in the body → executed, 200 { data: { id, deleted: true } } with a hint that repeats the numbers.

The token is bound to the account, the project, this user and the state of the target — if the person wrote in between, the summary is stale and the API answers 428 with a fresh one. Single-use, 5 minutes.

What the cascade does: the person's rows in prive and journal tables are destroyed; their rows in every other preset stay with a frozen owner_id, which nobody can edit any more (they can still be deleted); every file they uploaded is destroyed, public ones included; their sessions die; they leave their spaces; their seat is freed. An unknown user answers the neutral 404, the same as a user of another project.

A password-reset link#

Handing someone a way to take over an account requires the same ceremony as destroying it: a signed-in human, then the two-step confirmation with a token bound to this user.

  • reset_url points to GET /v1/auth/reset-password/:token on the project's data host. It is an API route that returns JSON, not a page: the app consumes it and leads the person where it wants.
  • expires_in is 3600 — one hour.
  • The link is single-use. Verifying it does not consume it; consuming it kills every open session of that person.
  • Until the link is used, nothing changes: the person keeps their password and their sessions. The link cannot be recalled.

On a project in read-only mode#

Deleting a user and issuing a reset link keep working on a project above its quota: they free or restore, they never create.