I Tried Connecting an OpenAI-Compatible API to WordPress AI

I was curious about something while testing WordPress AI features:

What happens if the AI provider I want to use is not one of the default providers?

WordPress AI can connect to supported providers directly, but many AI services today expose an OpenAI-compatible API instead of being officially supported one by one.

That includes things like:

• OpenRouter
• OpenWebUI
• Ollama
• LiteLLM
• other custom OpenAI-compatible endpoints

At first, I assumed that if an API follows the OpenAI format, I could just paste the endpoint somewhere and call it a day.

Turns out, not always.

So I tested a bridge approach using a WordPress plugin called Koneek to connect an OpenAI-compatible API provider to WordPress AI.

Here is what I found.

The thing I wanted to test

The question was simple:

Can WordPress AI use an OpenAI-compatible provider even if WordPress does not support that provider directly?

In my test, I used OpenRouter as the provider because it exposes an OpenAI-compatible endpoint and also has free models available.

The goal was not to build a custom integration from scratch.

I wanted to see whether WordPress AI could use a third-party compatible API through configuration only.

Why OpenAI-compatible APIs are not always plug-and-play

This part surprised me a little.

Even when a provider says it is OpenAI-compatible, it does not mean every app can automatically use it.

Different providers may use:

• a different base URL
• custom authentication behavior
• extra headers
• different model naming
• slightly different endpoint expectations
• different timeout behavior

So even if the request and response format is mostly compatible, WordPress still needs a way to know:

• where to send the request
• which model to use
• which API key to send
• how long to wait for a response

That is where the plugin comes in.

What I used

For this test, I prepared:

• WordPress 7.0
• the official WordPress AI plugin
• the Koneek – AI Provider for OpenAI-Compatible plugin
• an OpenAI-compatible API key
• a model name
• the provider base URL

For OpenRouter, the base URL I used was:

https://openrouter.ai/api/v1

For the model, the original test used:

cohere/north-mini-code:free

The exact model can change depending on what is available from your provider, so I would not hardcode that forever. Always check the provider's model list before configuring it.

The setup flow I tested

After installing and activating the required plugins, I went into:

Settings > Koneek

From there, I added a new provider configuration.

The fields were pretty straightforward:

Name: Any label you want
Provider: OpenAI-Compatible
API Key: Your provider API key
Model: The model name from your provider
API URL: The OpenAI-compatible base URL
Timeout: Optional

For OpenRouter, the important values looked like this:

Provider: OpenAI-Compatible
Model: cohere/north-mini-code:free
API URL: https://openrouter.ai/api/v1

I left the timeout empty at first because I wanted to see whether the default behavior was good enough.

If the provider is slow or the model takes longer to respond, setting a custom timeout may be worth testing.

Testing before saving was the useful part

One thing I liked about this workflow is that I did not have to blindly save the config and hope it worked.

Before saving, I tested the connection.

This is important because there are several small things that can break the setup:

• invalid API key
• wrong base URL
• typo in the model name
• provider-side rate limit
• free model no longer available
• timeout too low

In my case, once the connection test returned successfully, I saved the configuration.

That small test step saves a lot of guessing.

Enabling WordPress AI features

After the provider was connected through Koneek, the next step was enabling the AI features from:

Settings > AI

This part depends on the WordPress AI plugin configuration.

Once enabled, WordPress AI could use the configured provider for features like:

• rewriting text
• rephrasing content
• regenerating titles
• other editor AI actions

That was the moment where the setup actually felt useful.

The provider was not just saved somewhere in settings. It became usable inside WordPress.

What worked well

The biggest win is flexibility.

Instead of waiting for WordPress AI to support every provider directly, this setup makes it possible to connect providers that expose an OpenAI-compatible API.

That opens the door to testing different backends, such as:

• hosted AI providers
• local AI gateways
• self-hosted OpenWebUI
• LiteLLM routers
• OpenRouter model routing
• internal proxy APIs

For developers, that is useful because AI providers change fast.

Today you may want OpenRouter. Tomorrow you may want a local Ollama setup behind an OpenAI-compatible proxy.

The WordPress side does not need to care too much as long as the bridge configuration works.

The trade-offs I noticed

This setup is convenient, but I would not treat it as magic.

There are still a few things to watch:

Model names matter

OpenAI-compatible providers often use their own model naming format.

For example, OpenRouter model names usually look different from OpenAI model names.

If the model name is wrong, the connection may fail even if the API key and base URL are correct.

Free models may change

If you use a free model, do not assume it will stay available forever.

This is fine for testing, but for production workflows, I would use a stable paid model or at least have a fallback plan.

Timeout may need tuning

Some models respond slower than others.

If WordPress keeps failing while the provider works elsewhere, timeout settings are one of the first things I would check.

API keys still need to be protected

According to the Koneek plugin information, API keys are stored using AES-256-CBC encryption with the encryption key derived from WordPress secret salts in wp-config.php.

That is better than storing plain text secrets, but I would still treat API keys seriously:

• do not reuse important keys everywhere
• rotate keys if you suspect exposure
• avoid giving unnecessary permissions
• keep wp-config.php secure

When I would use this approach

I would use this setup when I want WordPress AI to work with a provider that is not directly supported yet.

Good use cases:

• testing multiple AI providers
• using OpenRouter for model routing
• connecting an internal OpenAI-compatible gateway
• experimenting with local or self-hosted AI
• avoiding vendor lock-in
• giving WordPress AI access to cheaper or specialized models

I probably would not use a random free provider for serious production content automation unless I had already tested its reliability, latency, and privacy policy.

The main thing I learned

The interesting part is that "OpenAI-compatible" is more of a compatibility layer than a universal guarantee.

It gives you a common API shape, but the app still needs to know the provider details.

Once those details are configurable, WordPress AI becomes much more flexible.

The setup that worked for me was:

WordPress AI
    ↓
Koneek provider configuration
    ↓
OpenAI-compatible API endpoint
    ↓
AI provider/model

That is a pretty clean flow.

Final thoughts

I went into this assuming the hardest part would be the API itself.

It was not.

The real trick was making WordPress AI aware of the provider's base URL, model name, and authentication details.

Once that bridge existed, the rest felt surprisingly simple.

While researching this setup, I also came across an Indonesian article that walks through a similar configuration: Cara Menghubungkan OpenAI-Compatible API ke WordPress AI

I am curious how other WordPress developers are approaching this.

Are you using official AI providers only, or are you routing everything through OpenAI-compatible gateways like OpenRouter, LiteLLM, Ollama, or OpenWebUI?