Clients & API

The XWMS API allows developers to integrate authentication, user management, and account-related services directly into their own applications.

To access the API, you first create an XWMS account, activate a client plan, and then create a client application in the dashboard to receive credentials.

API credentials are your client ID and client secret, used to identify and authorize your application when communicating with XWMS.

You can find the client ID in the Clients section of your XWMS Client dashboard.

A client secret is generated automatically when you create a new client application.

Yes. You can regenerate the secret in client settings. After rotation, update your application immediately to avoid authentication failures.

If credentials are exposed, rotate the client secret immediately and revoke any compromised tokens or access paths.

Yes. Full API documentation is available in the developer docs at docs.xwms.nl.

The XWMS API uses OAuth 2.0 for secure authentication and authorization.

Yes. The XWMS API follows REST principles and returns structured JSON responses.

OAuth is an authorization standard that lets applications access protected user data without sharing user passwords.

Your app redirects the user to XWMS for login and consent. After successful authentication, XWMS returns an authorization code to your application.

An authorization code is a short-lived code that your backend exchanges for an access token.

An access token is a temporary credential used to call protected API endpoints on behalf of a user or client.

A refresh token allows your application to request a new access token without forcing the user to log in again.

Token lifetime depends on your configured security policy and client setup.

Yes. Tokens can be revoked through the dashboard or supported API revocation mechanisms.

Supported flows include common OAuth patterns such as Authorization Code flow. Always use the flow that matches your app type and security requirements.

Yes. Mobile apps can integrate OAuth securely, typically using PKCE-enabled authorization flows.

Yes. Web applications commonly implement Authorization Code flow on a secure backend.

A client is an application registration that connects to the XWMS API and defines credentials, redirects, and permissions.

Go to the Clients section in the dashboard and create a new client with the required settings.

Yes. You can create multiple clients for separate apps, teams, or environments such as development and production.

Redirect URLs can be managed in each client's settings. Use exact callback URLs that your application actually handles.

Exact URI matching prevents open redirect abuse and ensures authorization responses are only sent to trusted endpoints.

Yes. You can register multiple redirect URIs for a client, for example for local, staging, and production environments.

Yes. You can temporarily disable a client to block authentication and API usage without permanently deleting it.

Deleting a client invalidates associated credentials and tokens, so existing integrations stop working.

Yes. Client names can be updated in the dashboard for clearer management.

Yes, as long as they have the required account permissions for client management.

Yes. Rate limits can apply based on your active subscription and service profile.

Requests above the allowed limit may return a rate-limit response until the limit window resets.

API usage metrics and request activity are available in your dashboard.

Yes. Higher limits are often available through plan upgrades or custom enterprise agreements.

Yes. Many endpoints support pagination to process large datasets efficiently.

API responses are typically returned in JSON format.

Errors are returned with HTTP status codes and structured error messages to help diagnose issues quickly.

Some integrations include webhook support for near real-time event notifications.

Yes. You can test locally using tools like Postman or curl, as long as your credentials and callback URLs are configured correctly.

SDK availability depends on supported languages and current platform roadmap.

Store API keys on secure backend systems only, preferably in protected environment variables and secret managers.

No. Client secrets must never be exposed in frontend code and should only exist on secure server-side infrastructure.

Use HTTPS, secure key storage, strict redirect validation, and environment-based configuration management.

Yes. API traffic must use HTTPS to protect credentials and data in transit.

Domain restrictions may be available depending on your client configuration and security settings.

Check response payloads, status codes, request parameters, and server-side logs to identify the root cause.

Verify client credentials, token validity, redirect configuration, and recent API error responses first.

Yes. Logging request and response metadata helps monitor integrations, performance, and incident investigations.

Yes. XWMS monitors suspicious traffic patterns and may restrict abusive behavior to protect platform stability.

Developer support is available through the support portal and official developer contact channels.

Most secured API endpoints require X-Client-Id, X-Client-Secret, and X-Client-Domain headers. These identify the client, authenticate the secret, and let XWMS verify that the request is coming from an allowed domain configuration.

XWMS resolves the client and domain from the request headers, verifies that the client secret is active, checks that the domain is allowed, and enforces domain settings such as active status, authentication access, API access, server IP allowlists, and test or live mode rules.

Yes. API access is tied to client domain settings, so a domain can be active or inactive, allowed or blocked for authentication, allowed or blocked for API access, and optionally restricted through server IP allowlist logic.

Live mode expects HTTPS so credentials, tokens, and user data are not sent over insecure production traffic. HTTP is mainly tolerated for test-mode or local development style configurations.

The sign-token and sign-token-verify endpoints are configured as free. Other endpoints such as user info, user address, countries, or default paid API requests can be billed by usage.

The current endpoint price configuration sets user info, user address, countries, and the default paid API request fallback at EUR 0.000010 per request.

XWMS Clients Basic is free and intended for a single client workspace with up to three domains, OAuth sign-in, and an included monthly request allowance before paid endpoint usage applies.

XWMS Clients Enterprise is the paid XWMS Clients plan at EUR 29 per month. It unlocks XWMS Clients without hard limits for clients, domains, members, roles and secrets, with usage-based API billing and support.