AuthMind API (1.0.0)
Welcome to AuthMind API documentation. This guide is designed to help developers understand how to integrate and interact with our APIs effectively. Here, you will find detailed information on the various endpoints, request and response formats, authentication mechanisms, and best practices for using our APIs.
AuthMind APIs are built to provide seamless access to our services, allowing you to enhance your applications with powerful features and functionalities. Whether you are looking to retrieve data or manage resources, our comprehensive API documentation will guide you through each step of the process.
Getting Started: Learn how to generate tokens to access the APIs and API documentation.
Endpoints: Detailed descriptions of each endpoint, including parameters, request, and response structures.
We are committed to providing a user-friendly API experience. Let's get started!
- Log in to AuthMind and go to the Admin section.
- From the left navigation, click API Tokens. The Manage API Tokens page is displayed
- From the top-right side, click Add. The Add API Client dialog is displayed.
- Enter a name for the client.
- By default, a one-year expiration date is set from the creation date of the token. You can change this date, as required.
- Click Submit. A success message is displayed. You can also see a Token Details dialog that contains the API token (JWT).
- Copy the token.
- Click OK to close the Token Details dialog. You can see the token is listed on the Manage API Tokens page.
This OpenAPI document is structured so autonomous agents can discover endpoints, understand required inputs, call the API safely, and parse responses.
Use the AuthorizationHeader security scheme for authenticated endpoints. The token is generated from the AuthMind Admin > API Tokens flow described above. When you create the token you choose the permission scopes to grant it (admin/user, posture, issues, or playbooks); each endpoint below documents the specific scope it requires. A token that lacks the required scope receives 403 Forbidden.
The server URL is documented as {{.Host}}/amapi. Replace {{.Host}} with your AuthMind tenant's base URL — the same origin you use to reach the AuthMind UI (for example https://<tenant>.authmind.com for AuthMind SaaS, or your self-hosted AuthMind domain).
Several list endpoints use from and size, but this is not a single global convention — treat each endpoint's own parameter description as authoritative:
/v1/issues,/v1/identities,/v1/assets,/v1/accesses,/v1/identitysystems,/v1/playbooks,/v1/users,/v1/issue/{incident_id}/accesses, and the*/hosts/*/sourcehosts/*/destinationhostsendpoints:fromis a one-based page number (default1) andsizeis the page length (default50; maximum1000, except100for the host-listing endpoints and no enforced maximum for/v1/users)./v1/getIssuesand/v1/getIssueDetailsare the exception:fromis a zero-based row offset (default0) andsizeis the row limit (default1000).
Some filters expect YYYY-MM-DD HH:MM:SS; some response fields are marked date-time. Use the format documented on the specific parameter. AuthMind stores and returns these values in UTC: query-parameter filters use YYYY-MM-DD HH:MM:SS (interpreted as UTC), and response timestamp fields are serialized as ISO-8601/RFC3339 in UTC (for example 2024-07-01T10:31:42.000Z).
Most endpoints return a success boolean and, on failure, one of error, errors, or message (the field name varies by schema — see the referenced response schema for the one that applies). These text fields are free-form and human-readable; AuthMind does not currently define a stable, cross-endpoint machine-readable error-code contract for them. Build integration logic around the HTTP status code and the success boolean, not the contents of these text fields.
Every endpoint on this page is rate-limited by the API gateway to 50 requests/minute per company (keyed on the X-Company-Id claim embedded in your token). Exceeding it returns 429 Too Many Requests; there is no Retry-After header, so back off and retry after a few seconds within the 1-minute window.
POST /v1/user is not an upsert: creating a user with an email that already exists on an active user returns 400 Bad Request (Email already taken.) rather than silently succeeding. PATCH/DELETE /v1/user require exactly one of id or email and act on the single matching active user, so retrying an identical PATCH/DELETE call is safe once the target no longer matches (e.g. after a successful delete, a repeat delete returns 404 Not Found).
Yes — every list endpoint applies a deterministic default sort server-side even when sort_by/order_by (or order) are omitted. /v1/issues and /v1/getIssues default to descending by generation/issue time; the posture list endpoints (/v1/identities, /v1/assets, /v1/accesses, /v1/identitysystems, and their */hosts endpoints) default to descending by latest activity time. See each endpoint's sort_by/order_by parameter description for the exact default field name.