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.