Clients & API

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

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.

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

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

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

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

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

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

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.

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

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.