API keys are the primary authentication method for DMSI Advanced API. Each key is a long-lived credential tied to a specific set of permissions (scopes), an optional IP whitelist, an optional expiry date, and a rate limit tier assignment.

What This Extension Adds #

Core DDLS uses WordPress Application Passwords for any REST API calls. DMSI Advanced API replaces this with a purpose-built API Key system that provides:

• Key format: dmsi_key_* prefix for easy identification in logs, environment variables, and configuration files
• Scope enforcement: granular per-key permissions (e.g., customers:read, licenses:write) so each integration receives only the access it requires
• IP whitelisting: restrict each key to one or more specific IP addresses or CIDR ranges
• Tier-based rate limiting: assign one of four rate limit tiers (Free, Professional, Business, Enterprise) per key, or set a custom per-key override
• Expiry management: set optional expiration dates; 7-day advance email warnings are sent automatically via a daily WP-Cron job
• Key rotation: revoke an old key and replace it with a new one without downtime — the old key record is preserved for audit purposes

Key Format #

Every API key follows this format:

dmsi_key_<40 hex characters>

Example (illustrative only):

dmsi_key_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

Total length: 49 characters (dmsi_key_ = 9 chars + 40 hex chars).

Key Storage #

API keys are never stored in plaintext. The storage mechanism is:

• The full key is bcrypt-hashed (cost factor 12) and the hash is stored in the dmsi_aapi_keys database table
• The first 12 characters of the random portion are stored as a key_prefix field for fast lookup — only rows matching the prefix are bcrypt-verified, avoiding full table scans
• The full key is displayed exactly once at the moment of creation and cannot be retrieved afterward

Key Lifecycle #