Docs
Sign in
Documentation

REST API

The Inth API is the machine-facing control plane for Inth. Use it to provision and manage projects, inspect organizations, and manage API keys — everything the dashboard does for humans, over JSON for programs. Consent is one of the products available inside an Inth project.

Authentication

The API uses organization API keys — service credentials owned by an organization, not by an individual user. Pass the key as a bearer token:

curl https://api.inth.com/v1/projects \
  -H "Authorization: Bearer inth_..."

How keys work:

  • Create keys in the dashboard under Organization settings → API Keys, or with the create key endpoint using a signed-in user's credentials. The inth_... secret is shown once at creation.
  • Keys act as the organization. Every request runs with organization-wide access; there are no per-key scopes yet. Treat a key like a deploy credential, not a user session.
  • Keys cannot manage keys. Creating, rolling, and deleting keys always requires a user principal, so a leaked key cannot mint successors that outlive its revocation.
  • Rotate with roll. Rolling issues a new secret for the same key identity and revokes the old secret immediately.
  • Plan requirements. API access requires the Starter plan or higher — see rate limits for per-plan limits, plan-gating behavior, and key caps.

The MCP endpoint is the exception: it uses user-delegated OAuth instead of API keys, so agents act as the signed-in user. Point an MCP client at https://api.inth.com/mcp and it discovers the authorization server through the protected resource metadata.

Responses

Every endpoint wraps its result in a stable envelope:

{ "success": true, "data": { } }

List endpoints return data as an array plus a pagination object. Pass pagination.nextCursor back as the cursor query parameter to fetch the next page:

{
  "success": true,
  "data": [{ "projectId": "prj_123" }],
  "pagination": { "nextCursor": "cHJqXzEyMw", "hasMore": true }
}

Errors use the same envelope with success: false and a machine-readable error.code (for example UNAUTHORIZED, PLAN_REQUIRED, RATE_LIMITED, NOT_FOUND); validation failures add an error.details array with per-field issues:

{
  "success": false,
  "error": {
    "code": "NOT_FOUND",
    "message": "Project not found"
  }
}

Every response carries an X-Request-Id header — include it when reporting an issue.

Stability

Within v1, changes are additive: new fields, new endpoints, and new enum values may appear at any time, and clients should ignore fields they do not recognize. Breaking changes ship under a new version prefix.

Resource IDs are prefixed strings — prj_ projects, org_ organizations, ins_ consent instances, key_ API keys. Treat them as opaque; the prefix only tells you what kind of resource an ID refers to.

Endpoints

System

Auth

Organizations

Projects