Jentic

Jentic Users API

Part of the **Admin / Audit** bounded context — the human roster of the organisation. One organisation, many users; admin surfaces here cover create / list / read / update / delete plus the AIP-style action verbs (`:disable`, `:enable`, `:reissue-invite`). Self-service is intentionally minimal: `GET /users/me` to introspect, `POST /users/me:change-password` to rotate (which re-mints and returns a fresh token, clearing any `must_change_password` gate so the caller need not re-login). **First-run setup (no default credentials).** The platform ships with an empty users table — there is no seeded `admin@local` account. On a fresh install `GET /health` reports `setup_required: true` (with `next_step: create_admin`). The operator creates the first administrator via `POST /users:create-admin {email, password}`: a one-time, unauthenticated endpoint that succeeds only while no user exists, grants `org:admin`, and returns an auto-login `LoginResponse` with `must_change_password: false` (the operator chose the password, so there is no forced rotation). It **self-closes** — once any user exists it returns `410 setup_already_complete`, so it is safe to leave exposed during first boot; a single-row setup sentinel is the concurrency backstop against racing callers (even ones using different emails). After the first user exists, `setup_required` flips to `false`. **Onboarding flow.** Admins create new users via `POST /users` (no password supplied). The response carries a one-time `inv_…` invite token shown **once**; the admin hands it off out-of-band (Slack, 1Password, email — there is no platform-side email infrastructure in this revision). The new user redeems via `POST /users:redeem-invite {invite_token, password}` and is auto-logged-in via the returned `LoginResponse`. Tokens default to a 7-day TTL and are single-use; `:reissue-invite` issues a fresh one if the original is lost or expired. **Authentication.** Today only local (username + password) identity ships. The `User` schema carries `auth_provider: local | external` and an `external_subject_id` field reserved for future SSO integrations (Okta, Cognito, Azure AD); when SSO arrives, those users will be created via a separate provider-specific router. The on-the-wire token contract — `Authorization: Bearer ` — is unchanged either way. **Disabling and revocation.** `:disable` flips `active=false` and rejects subsequent `POST /auth/login` **and** `POST /auth/refresh`. **Existing JWTs keep working until they expire** (≤ 1 hour with the platform's default TTL). This is a deliberate trade-off; sub-minute revocation would require a server-side session table. **Session lifetime.** Login JWTs carry a 1-hour TTL. The UI keeps an active session alive by calling `POST /auth/refresh` before expiry (sliding session); refresh re-reads permissions and the `must_change_password` gate from the database and is refused with 401 `session_expired` once the original authentication is older than the absolute window (`admin.auth.session_ttl_seconds`, 12 hours by default), forcing a fresh login.

Documentation GitHub OpenAPI

Operations 15

POST /auth/refresh Refresh session token #

GET /users List Users #

POST /users Create User #

GET /users/me Get current user #

POST /users/me:change-password Change own password #

DELETE /users/{user_id} Delete User #

GET /users/{user_id} Get User #

PATCH /users/{user_id} Update User #

PUT /users/{user_id}/permissions Set User Permissions #

POST /users/{user_id}:disable Disable User #

POST /users/{user_id}:enable Enable User #

POST /users/{user_id}:reissue-invite Reissue Invite #

POST /users:create-admin Create first admin (one-time setup) #

POST /users:redeem-invite Redeem invite #

Specifications

⚙

OpenAPI

https://artifacts.apis.io/jentic/openapi/jentic-users-api-openapi.yml

Work with this as data

Every API here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for apis

7 MCP tools reach this

find_apisBrowse and filter every API in the catalog.
get_api_artifactsOne API's artifacts, grouped by type.
get_openapiThe primary OpenAPI for this API.
find_similar_apisAPIs that look like this one.
apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
resolveTurn a domain, URL or GitHub org into the provider it belongs to.
find_cohortsEvery scored population of providers in the catalog.

All 92 tools →

Call it yourself

curl for this page

This API

curl "https://apis.io/api/v1/apis/jentic:jentic-users-api"

All apis

curl "https://apis.io/api/v1/apis?limit=25"

Calls without X-API-Key need no key. Calls with it need a paid plan — get a key.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

GitHub Google LinkedIn

A second provider on the same verified email joins the account you already have.

OpenAPI Specification

openapi: 3.2.0
info:
  contact:
    email: support@jentic.com
    name: Jentic Platform Team
    url: https://jentic.com/
  description: '## Overview ##

    The **Jentic Control Plane API** is the unified HTTP surface of the

    Jentic platform''s control plane — every administrative and

    metadata-facing endpoint outside the Broker data plane. The control plane is the administrative counterpart to the

    Broker data plane: where the Broker executes

    upstream API calls on behalf of agents, the control plane is where

    humans, operators, and agents configure *what* the Broker is

    allowed to do, *for whom*, *with which credentials*, *against

    which registered APIs*, and *with what telemetry retained*. ## Components ##

    High-level components for the control plane API. - **Core / Access** — credentials, toolkits,

    and PBAC grants and runtime params. Owns *who can call what, with which secret*. - **Registry** — registered APIs, immutable

    revisions, operations, search, lookup. Owns *what APIs are

    registered for this deployment and what they look like at any

    given revision*. - **Admin / Audit** — users, permissions,

    execution telemetry, async-job tracker, and dashboard event

    stream. Owns *who can sign in with what permissions* together

    with *what actually happened* — the human roster, the

    append-only records of brokered executions, the unified

    `Job` resource that both Registry imports and Broker

    async-execution calls feed into, and a curated `/events`

    surface for dashboards and operators. ## Authentication ##


    Today the platform ships a local username + password identity

    provider for human users, alongside agent identity (Dynamic Client

    Registration + RFC 7523 JWT-bearer assertions) and service-account

    client credentials — every authenticated operation expects

    `Authorization: Bearer ` (`BearerAuth`, an opaque `at_`

    token) except `GET /health`, `POST /auth/login`,

    `POST /users:create-admin`, and `POST /users:redeem-invite`. Human tokens are issued by `POST /auth/login` with a fixed 1-hour

    TTL and can be re-minted before expiry via `POST /auth/refresh`

    (sliding session, bounded by an absolute window —

    `admin.auth.session_ttl_seconds`, 12 hours by default); agents and

    service accounts obtain tokens from `POST /oauth/token` (see

    `BearerAuth`). The `permissions` claim on a token is a snapshot at

    issue time; permission changes take effect at the next re-issue —

    the next refresh or re-login (≤ 1 hour with the default TTL). The platform ships **no default credentials**. On a fresh

    install the users table is empty, so `GET /health` returns

    `setup_required: true` with `next_step: create_admin`. The

    operator creates the first administrator with `POST

    /users:create-admin {email, password}` — a one-time,

    unauthenticated, self-closing endpoint: it succeeds only while

    the users table is empty and returns `410 setup_already_complete`

    once any user exists (a single-row setup sentinel is the

    concurrency backstop, so two racing callers — even with different

    emails — cannot both bootstrap). It grants `org:admin`, sets the operator''s chosen

    password (so `must_change_password` is **false** — no forced

    rotation), and returns a ready-to-use `LoginResponse`

    (auto-login). After the first user exists `setup_required` flips

    to `false`. See the **Users** tag for the full onboarding

    walkthrough. External SSO providers (Okta, AWS Cognito, Auth0, Azure AD)

    plug in via the `User.auth_provider: external` hook plus an

    `external_subject_id` mapping; no concrete provider ships in

    this revision. Agent identity (separate from human users) uses

    Dynamic Client Registration (`POST /register`) with the agent''s

    JWKS, then RFC 7523 JWT-bearer assertions exchanged at

    `POST /oauth/token` for an opaque access token. ## Cross-cutting conventions


    - Every API reference uses the loose

    `APIReference(vendor, name, version)` data structure. There is no

    foreign key between Core, Registry, and Admin / Audit — the

    tuple is the only join. - **Error shape.** Every error response is RFC 9457 Problem

    Details (`application/problem+json`) using the shared

    `ProblemDetails` schema from

    jentic/api-problem-details.'
  license:
    identifier: Apache-2.0
    name: Apache-2.0
  summary: HTTP surface of the Jentic platform's control plane — Core / Access (credentials, toolkits), Registry (registered APIs, operations, search), and Admin / Audit (execution telemetry, async jobs).
  title: Jentic Control Plane Users API
  version: 0.39.0
servers:
- description: Same-origin (relative)
  url: /
security:
- BearerAuth: []
tags:


# --- truncated at 32 KB (70 KB total) ---
# Full source: https://artifacts.apis.io/jentic/openapi/jentic-users-api-openapi.yml