WordPress 7.0 Connectors API: The Real Fix For API Key Chaos

WordPress 7.0 Connectors API replaces every plugin’s home-grown API key settings page with one core admin screen at Settings → Connectors. The plugin author no longer ships a settings form. The site owner no longer types the same OpenAI key into three different plugins. Both halves of the problem just got solved.

This is the first single-feature deep dive in the “Inside WordPress 7.0” series — a companion to the WordPress 7.0 Deep Dive that walked every major feature in the release. Here the focus is one architectural shift in detail, with real PHP code and the two honest catches viewers should know before shipping anything against this API.

The problem the WordPress 7.0 Connectors API solves

Before WordPress 7.0, every plugin that talked to an external service shipped its own settings page. Its own API key field. Its own validation. Its own storage. WPForms had one for Stripe. Yoast had one for OpenAI. Mailchimp for WordPress had one for Mailchimp. Each plugin author wrote the same boilerplate, each site owner typed the same keys into three different places, and rotating a leaked key meant hunting through every plugin’s settings screen.

WordPress 7.0 Connectors API turns that into one shared registry. The plugin author registers their external service against a core API. The site owner sees every plugin’s connectors as cards on one admin screen at Settings → Connectors. The key gets stored once. Every plugin reads from the same store.

Registering a connector

Registration happens in a single action hook callback. The hook is wp_connectors_init, which fires during the standard init action after WordPress core has registered its built-in connectors and auto-discovered AI providers. The callback receives a WP_Connector_Registry instance; the plugin author calls register() on it with an id and an args array:

<?php
// ai-provider-for-anthropic/plugin.php

add_action( 'wp_connectors_init', function ( WP_Connector_Registry $registry ) {
    $registry->register( 'anthropic', array(
        'name'           => 'Anthropic',
        'description'    => 'Text generation with Claude.',
        'type'           => 'ai_provider',
        'authentication' => array(
            'method'          => 'api_key',
            'credentials_url' => 'https://platform.claude.com/settings/keys',
            'setting_name'    => 'connectors_ai_anthropic_api_key',
        ),
    ) );
} );

Required fields are name, type, and authentication. The authentication block’s method in WordPress 7.0 is either api_key or none; credentials_url is the page where the user gets a key, and setting_name is the wp_options key WordPress will store the value under (auto-generated if omitted). Optional fields include description, logo_url, and a plugin reference. That is the whole registration. No form. No validation callback. No render function. WordPress core handles the UI, the storage, and the masking.

Connector ids must match /^[a-z0-9_-]+$/. Attempting to call registry methods outside the wp_connectors_init action triggers a _doing_it_wrong() notice. Full documentation is on the Make WordPress Connectors API dev note.

Querying the registry from any plugin

Reading from the registry happens through three public functions, callable from anywhere after the init action:

<?php
// Check whether a provider is registered.
if ( wp_is_connector_registered( 'anthropic' ) ) {
    $connector = wp_get_connector( 'anthropic' );
    echo $connector['name']; // "Anthropic"
}

// Iterate every registered connector.
foreach ( wp_get_connectors() as $id => $connector ) {
    printf( '%s: %s', $connector['name'], $connector['description'] );
}

The typical use case is: a plugin needs to call an AI provider, so it checks wp_is_connector_registered() before assuming the credential exists. If a different plugin already registered Anthropic and the site owner already pasted the key, the second plugin uses the stored credential without asking the user to enter anything.

Where the key actually lives

When a plugin calls wp_get_connector('anthropic') to read the credential, WordPress checks three sources in order:

1. An environment variable matching the provider naming convention — e.g. ANTHROPIC_API_KEY set on the host.
2. A PHP constant defined in wp-config.php — e.g. define( 'ANTHROPIC_API_KEY', 'sk-...' );.
3. A database setting with the auto-generated or explicit name — e.g. connectors_ai_anthropic_api_key in wp_options, which is what the user types into Settings → Connectors.

The first match wins. Production sites can keep keys entirely out of the database by setting environment variables on the host — cleaner for credential rotation. Local development sites and small-scale deployments can use the UI for convenience. For sites already targeting PHP 8.4, the recommended approach is environment variables managed via .env tooling or the host’s control panel.

The two honest catches

The Connectors design ships with two known trade-offs that plugin authors should understand before building against it.

Catch 1 — the credentials are site-wide, not per-plugin scoped. Once the site owner stores an API key through Settings → Connectors, every plugin installed on the site can read it. There is no permission system saying “only the Mailchimp plugin can read the Mailchimp key.” The dev note acknowledges this explicitly: “It’s the site setting, so every plugin can access it.” For most cases this is fine because the plugins are already trusted, but it is a real change from the per-plugin model where Plugin A had no way to read Plugin B’s stored credentials.

Catch 2 — database storage is not encrypted in WordPress 7.0. The Settings → Connectors UI masks the key value with dots, but the underlying wp_options row holds it as plaintext. Anyone with database access can read it. Encryption at rest is being explored in a follow-up Trac ticket. For now, the WordPress 7.0 Connectors API recommends environment-variable or PHP-constant storage in production, with the database setting reserved for local development.

What plugin authors should do now

Three practical takeaways for anyone shipping a plugin that talks to an external service:

• For new plugins: register against the WordPress 7.0 Connectors API instead of building a custom settings page. The amount of code shrinks by ~80%; the user experience matches every other plugin on the site.
• For existing plugins: consider a migration path where the legacy settings page stays for backwards compatibility on older WordPress versions, but newer installs detect WordPress 7.0+ and prefer the Connectors registry. The official WordPress 7.0 Field Guide links every dev note relevant to such a migration.
• Document the catches to users: if the plugin handles sensitive credentials, make the README clear that keys stored via Settings → Connectors are visible to every other installed plugin and are unencrypted at rest in WordPress 7.0.

The WordPress 7.0 Connectors API is the architectural shift that every AI integration plugin will build against for the rest of 2026. The current site-wide-scope and unencrypted-at-rest gaps are documented and likely to evolve in a 7.x point release.

Watch the companion long video above for the full walkthrough with architecture diagram, or catch the 3-minute breakdown in the companion Short. Next in the “Inside WordPress 7.0” series: the Navigation Overlay Designer.