Authentication

The API uses JWT (JSON Web Tokens) for authentication. There are two separate auth contexts:

Context	Login endpoint	Token type	Use case
Admin	POST /rest/auth/admin/login	Backend	Admin panel, product management, order management
Customer	POST /rest/auth/customer/login	Frontend	Storefront, customer account, wishlist, cart

Login

Send credentials as JSON:

POST /rest/auth/admin/login
Content-Type: application/json

{
  "username": "admin@example.com",
  "password": "your-password"
}

Successful response (200):

{
  "access_token": "eyJhbGciOiJIUzI1NiIs...",
  "refresh_token": "a1b2c3d4e5f6..."
}

The customer login endpoint works identically: POST /rest/auth/customer/login.

Using the Access Token

Include the access token in the Authorization header on every request:

GET /rest/product/product
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Refreshing Tokens

When the access token expires, use the refresh token to get a new one without re-authenticating:

POST /rest/auth/admin/refresh
Content-Type: application/json

{
  "refresh_token": "a1b2c3d4e5f6..."
}

Response (200):

{
  "access_token": "eyJhbGciOiJIUzI1NiIs..."
}

The refresh token itself does not rotate on refresh. Use POST /rest/auth/customer/refresh for customer tokens.

Customer Registration

POST /rest/auth/customer/register
Content-Type: application/json

{
  "email": "new@example.com",
  "password": "min6chars",
  "firstName": "John",
  "lastName": "Doe",
  "phone": "+30210...",
  "newsletter": true
}

Successful response (201) returns access_token and refresh_token directly, so the customer is logged in immediately.

Access Scopes

The token type determines the scope of each request, which affects what data is returned:

Scope	Token required	Description
Public	None	Anonymous access. Only public fields and relations are returned.
Customer	Customer JWT	Logged-in customer. Additional customer-specific fields and relations.
Backend	Admin JWT	Admin user. All fields and relations, including admin-only data.

Many endpoints are accessible publicly (product catalog, CMS pages, etc.) but return richer data when authenticated. See Response Scoping for details.

Roles (Backend Only)

Admin tokens carry role information. The API enforces role-based access on backend-protected endpoints:

Role	ID	Access
Advisable	1	Superuser — bypasses all role checks
Developer	2	Technical settings
Admin	3	General administration
CMS	4	Content management
Products	5	Product catalog
Orders	6	Order management
Reporting	7	Analytics
Marketing	8	Promotions and campaigns
Media	9	Media and sliders

If a backend endpoint requires a role you don't have, you'll receive a 403 Forbidden response.

Live Testing Notes

Response Structure

Auth endpoints return tokens at the root level of the JSON response, not nested under a data key:

{
  "access_token": "eyJhbGciOiJIUzI1NiIs...",
  "refresh_token": "a1b2c3d4e5f6..."
}

This differs from resource endpoints, which use a standard envelope:

{
  "success": true,
  "data": [...],
  "pagination": { "page": 1, "per_page": 20, "total": 150, "total_pages": 8, "has_next": true, "has_prev": false }
}

Keep this distinction in mind when building API clients: auth responses are unwrapped, everything else is enveloped.

Admin Login

POST /rest/auth/admin/login
Content-Type: application/json

{
  "username": "admin@example.com",
  "password": "your-password"
}

The username field accepts the admin's email address. Config-based static users (defined in application configuration) are checked before database users, so a static user with the same username will always take precedence.

Customer Registration

POST /rest/auth/customer/register
Content-Type: application/json

{
  "email": "new@example.com",
  "password": "min6chars",
  "firstName": "John",
  "lastName": "Doe"
}

The required fields are email, password, firstName, and lastName. Additional fields (phone, newsletter, etc.) are optional. A successful registration returns access_token and refresh_token at the root level, logging the customer in immediately.