WordPress 7.0 ships the Connectors API, and the documentation makes it look like a clean win for AI integration. Read the source and you find an initialization lifecycle plus a couple of security details worth knowing before you ship a plugin that leans on it.
Every AI plugin used to invent its own way of storing API keys and provider settings. The Connectors API replaces that with one registry for external services. The first release covers AI providers such as OpenAI, Anthropic and Google, but the architecture reads like it is meant to handle every external service WordPress talks to later on.
What a connector actually is
A connector is a metadata object with a fixed shape: the display name, the logo, and the authentication configuration that does the real work. If you already build on the WordPress Abilities API or the WP AI Client, you register nothing by hand. The system discovers providers from the registry and fills the UI in for you.
Modifying an existing connector is the more common job. Maybe you need a different description, or a swapped logo for a white-label build. That is what the wp_connectors_init hook is for.
Overriding the Connectors API registry
The registry is strict and rejects duplicate IDs, so changing a connector means unregistering it, editing the data, and registering it again. Check that the connector exists before you start, or you trigger a _doing_it_wrong() notice.
add_action( 'wp_connectors_init', function ( WP_Connector_Registry $registry ) {
if ( $registry->is_registered( 'anthropic' ) ) {
// Grab the existing data
$connector = $registry->unregister( 'anthropic' );
// Modify the description for a client site
$connector['description'] = __( 'Enterprise-grade Claude integration.', 'my-agency' );
// Register it back
$registry->register( 'anthropic', $connector );
}
} );API key priority and security
The authentication priority is the part I like. Keys are read from environment variables first, then PHP constants, then the database. I have been shouting about that order for years. Hardcoding a key is a disaster, so reach for an environment variable like ANTHROPIC_API_KEY whenever the host lets you.
There is a catch. API keys kept in the database are not encrypted. The UI masks them, but they sit in plain text in your wp_options table. The core team is tracking it in Trac #64789. Until that lands, keep sensitive client keys in server-level environment variables and skip the database.
For the wider picture on building integrations that hold up, I wrote a guide on Building a WordPress API Client The Right Way.
The initialization lifecycle
Timing is what you end up debugging. The _wp_connectors_init() function runs on the standard init action. It builds the registry, discovers providers, then fires the wp_connectors_init hook. Touch the registry outside that window and you get a silent failure more often than an error.
If this Connectors API work is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
Where it stands
The Connectors API in 7.0 is a decent first step toward standardizing how WordPress talks to outside services. It only handles ai_provider types with API key auth right now, but the base for a general connection layer is there. Keep your keys in environment variables, hook into wp_connectors_init instead of guessing at the timing, and verify a connector is registered before you unregister it. The official WordPress 7.0 Dev Note has the rest.
