How to Store AI API Credentials in a WordPress Integration

Storing an AI API credential in a WordPress integration comes down to two questions: where does the secret physically live, and who or what can read it? Since WordPress 7.0, the Connectors API gives the first question a standard answer for most sites — install a connector plugin from Settings > Connectors, paste the provider key, and the framework handles provider discovery and authentication configuration. If you are writing your own integration instead, you still choose between wp-config.php constants, environment variables, and the database, and each choice changes your exposure, portability, and backup risk.

This guide is for developers and site administrators who need to wire an AI provider into WordPress without leaking the key. It covers the documented WordPress 7.0 path first, then the storage patterns you control yourself.

What the Connectors API standardizes

WordPress 7.0 introduces the Connectors API, described by the core team as a new framework for registering and managing connections to external services. Its initial focus is AI providers, and it provides a standardized way to handle API key management, provider discovery, and the admin UI for configuring AI services.

Each connector carries standardized metadata: a display name, description, logo, authentication configuration, and an optional association with WordPress.org. The Settings Connectors screen ships with three featured connectors — Anthropic, Google, and OpenAI — and each one links to the provider’s site so you can create or copy the required credentials.

That is the important architectural point for credential storage: the Connectors API defines how a connection is registered and configured, not a single mandatory place where every key must be written. The public documentation describes the install-and-paste administrative flow; it does not spell out the internal storage or encryption mechanism of a given connector plugin. If that detail matters for your threat model, inspect the connector plugin you install or ask its maintainer rather than assuming.

Path A: let the connector plugin manage the key

For most sites this is the shortest path, and it is the one WordPress documents.

1. In the WordPress dashboard, go to Settings > Connectors.
2. Find the provider you want (Anthropic, Google, or OpenAI in the featured list) and select Install to install the connector plugin.
3. Activate the plugin.
4. Follow the connector’s link to the provider’s site and create or copy an API key.
5. Paste the key into the connector’s API key field and save.

Expected result: the connector appears as configured on the Settings > Connectors screen, and the credential is available to anything that queries that connector.

If you also want WordPress to use the connection for content tasks, install the AI plugin from the notice on the same screen. According to the documentation, the AI plugin can use your configured AI connectors to generate featured images, alt text, titles, excerpts, and other content, and it adds a Settings > AI screen for configuring AI features and experiments.

Verification: open Settings > AI. The plugin requires a valid AI connector; if none is configured, it displays a message asking you to verify that one or more AI connectors are configured. Seeing that message after you saved a key usually means the connector plugin is inactive, the key field is empty, or the key was rejected by the provider.

Path B: store the credential in your own integration

When you build a custom integration — a plugin, a theme function, or an automation that calls an AI provider directly — you decide where the secret lives. Three patterns cover almost every case.

Option 1: constants in wp-config.php

Define the key as a constant outside the database, then read it defensively.

define( 'MYPLUGIN_AI_API_KEY', 'your-key-here' );

if ( defined( 'MYPLUGIN_AI_API_KEY' ) ) {
    $key = MYPLUGIN_AI_API_KEY;
} else {
    $key = '';
}

Advantages: the key never enters the database, so it does not appear in typical database dumps, exports, or migration packages. It also cannot be changed from the admin, which limits the blast radius of a compromised administrator account.

Tradeoffs: changing the key requires file access and a deployment. There is no settings UI for non-technical users. And wp-config.php itself is a single point of failure — if it is committed to a repository or included in an insecure backup, the key leaks with it.

Option 2: environment variables

$key = getenv( 'MYPLUGIN_AI_API_KEY' );
if ( ! $key ) {
    return new WP_Error( 'missing_key', 'AI API key is not configured.' );
}

Environment variables keep the secret out of both the database and the codebase, which makes them a good fit for containerized and platform-as-a-service deployments. The catch is that availability is host-dependent: some managed WordPress hosts do not expose custom environment variables to PHP, and behavior can differ between web requests, WP-CLI, and cron. Confirm support with your host before standardizing on this approach. For local development, a .env file loaded by a library such as vlucas/phpdotenv is common, but that file must be excluded from version control.

Option 3: the options table through the Settings API

Registering a setting and storing the key with register_setting() and get_option() is the most WordPress-native option and the easiest to expose in an admin UI. It also works per site in a multisite network.

Tradeoffs: the key is stored in the database, often in plain text, and therefore travels with every database dump, staging clone, and migration. Anyone who can read the database — including whoever receives a backup — can read the key. Treat database storage as acceptable only when you also control who receives those dumps.

Rules that apply wherever the key lives

• Never commit credentials. Add .env, local config overrides, and any file holding a key to .gitignore before the first commit.
• Keep the key server-side. Do not print it into HTML, REST responses, or JavaScript. A browser-visible key is a public key.
• Check capabilities. Settings screens that display or change a key should require an appropriate capability such as manage_options, and form submissions should be protected with a nonce.
• Sanitize on input, escape on output. Even a key field is user input; strip unexpected characters and escape anything rendered back into the admin.
• Do not log secrets. Debug logging, error trackers, and HTTP client logs are common leak paths. Log a masked prefix instead of the full value.
• Scope the key at the provider. Many AI providers let you create keys restricted to a project or a limited set of permissions. A dedicated key for WordPress limits what a leak actually exposes.
• Use one key per site and environment. Separate production, staging, and local keys make it possible to revoke one without breaking the others.
• Plan rotation. Assume any key can leak, and keep a documented procedure for revoking and replacing it.

Troubleshooting common failures

Mask secrets in any log, screenshot, or forum post you share when asking for help — replace all but the first few characters with asterisks.

Limitations and open questions

The Connectors API in WordPress 7.0 is new, and its initial focus is AI providers. The public documentation covers the administrative flow, the featured connectors, and the metadata a connector carries; it does not document the internal storage or encryption of keys handled by connector plugins. Sites with strict compliance requirements should verify that behavior directly against the plugin they deploy rather than relying on an assumption.

Order of operations also matters. The AI plugin is only useful once a valid connector exists, so installing it before configuring a provider produces the “verify that one or more AI connectors are configured” message instead of a working setup. Configure the connector first, then install the AI plugin.

Next step

Pick one storage pattern and apply it consistently. If you are using the built-in path, confirm your connector shows as configured and then open Settings > AI to check that the plugin recognizes it. If you are building your own integration, start with a wp-config.php constant or an environment variable, keep the key out of version control, and write down how you would rotate it. Readers working through a specific host, connector plugin, or error message are welcome to share their environment and the exact error in the community so others can compare notes.