Authentication API

Overview

The Authentication API provides endpoints for obtaining Personal API Access Tokens, which are required for accessing all other Management API endpoints.

Authentication

The token creation endpoint does not require authentication. However, you must provide valid Apinizer credentials (username and password) to obtain a token.

Token Usage

Once you have obtained a token, include it in the Authorization header of all subsequent API requests:

Authorization: Bearer YOUR_TOKEN

Create Token

Endpoint

POST /apiops/auth/token

Request

Headers

Header	Value	Required
Content-Type	application/x-www-form-urlencoded	Yes
Accept	application/json	No

Request Body (URL Encoded)

The request body must be sent as application/x-www-form-urlencoded (not JSON).

Parameter	Type	Required	Description
grant_type	string	Yes	Must be client_credentials
client_id	string	Yes	Your Apinizer username
client_secret	string	Yes	Your Apinizer password

Full Request Body Example

grant_type=client_credentials&client_id=your_username&client_secret=your_password

Response

Success Response (200 OK)

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
  "token_type": "Bearer",
  "expires_in": 3600
}

Response Fields

Field	Type	Description
access_token	string	The Personal API Access Token to use for authentication
token_type	string	Always Bearer
expires_in	integer	Token expiration time in seconds (if applicable)

Error Response (400 Bad Request)

{
  "error": "unsupported_grant_type",
  "error_description": "GrantType value must be client_credentials!"
}

Cause: The grant_type parameter is not client_credentials.

Error Response (401 Unauthorized)

{
  "error": "unauthorized_client",
  "error_description": "Bad credentials"
}

Causes

• Unknown username
• Incorrect password
• Account is locked (too many failed sign-in attempts; an administrator lifts the lock under Users)
• Account is disabled

All four causes return the same status, body and headers — the response never reveals whether the account exists or what state it is in. The actual reason is recorded for administrators in Login Logs.

Error Response (500 Internal Server Error)

{
  "error": "server_error",
  "error_description": "An unexpected error occurred"
}

cURL Example

curl -X POST \
  "https://demo.apinizer.com/apiops/auth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Accept: application/json" \
  -d "grant_type=client_credentials&client_id=your_username&client_secret=your_password"

Full JSON Body Example

Note

This endpoint uses application/x-www-form-urlencoded format, not JSON. The example below shows the equivalent data structure:

{
  "grant_type": "client_credentials",
  "client_id": "your_username",
  "client_secret": "your_password"
}

Important: When making the actual request, send this data as URL-encoded form data, not as JSON.

Notes and Warnings

• Security: Never commit credentials or tokens to version control
• Token Storage: Store tokens securely (use environment variables or secret management)
• Token Expiration: Tokens may expire based on configuration. Check expires_in field
• Account State: An issued token is only as valid as the account behind it. Locking or deactivating the user under Users stops every token that user holds from being accepted on the next call — there is no grace period and the tokens do not need to be revoked separately. The refusal is a 401 with the same body as an unknown token, so it never reveals that the login exists.
• Expiration Is Enforced on Use: A token stops being accepted the moment its own expiration date passes, not when the periodic cleanup job next runs.
• Each Token Stands on Its Own: An account may hold several tokens at once. Every request is judged against the token it actually presents, so a revoked or expired token stays refused while a newly issued one is accepted from its first call — an older token can never cause a valid one to be rejected. Regenerating a token therefore takes effect immediately: the new value works, the old value does not. Revocation is by value as well: revoking a token removes every stored copy of it, so a value that happened to be stored more than once — after a regeneration, a user import or a restore from backup — stops authenticating completely.
• Token Format: Always use Bearer prefix when including token in Authorization header
• Content-Type: This endpoint requires application/x-www-form-urlencoded, not application/json

Related Documentation

• Authentication Guide - Detailed authentication information
• Error Handling - Error response formats