Calling an AI API from WordPress Without Wrecking the Site

Any API key that reaches the browser can be copied by anyone who opens the developer tools, and then used to run up charges on your account. That includes keys embedded in JavaScript, passed in a data attribute or returned by an unauthenticated AJAX endpoint. Calls to a model provider must start on your server.

In WordPress, that means a custom REST route or an admin action that receives the user's request, checks their permissions and a nonce, builds the prompt on the server and calls the provider with wp_remote_post. The browser only ever talks to your site. This also gives you one place to validate input, apply limits and log usage.

Plugins often store API keys in the wp_options table, which means every database backup, staging copy and export contains the key in plain text. Keys committed to a Git repository are worse, because they stay in its history even after removal.

Prefer an environment variable or a constant defined in wp-config.php, with wp-config.php itself excluded from version control and readable only by the web server user. Use a separate key for each environment so a leaked staging key cannot be used against production, and set the provider's own usage limits on each key. If you must accept a key through an admin screen, restrict the screen to administrators and never echo the full key back into the page.

Model responses can take several seconds, and longer for large outputs. A page that waits for one feels broken, and if many visitors trigger generation at once, PHP workers fill up and the whole site slows down. Anything that is not an interactive chat should run in the background.

Action Scheduler, which ships with WooCommerce and can be used as a standalone library, is a solid choice for queued jobs in WordPress. The request creates a job and returns immediately; a background runner calls the provider, stores the result in post meta or a custom table and marks the job complete. The admin screen polls or refreshes to show the result. WP-Cron alone is less reliable on low-traffic sites, because it only runs when someone visits, so pair it with a real server cron if you depend on it.

• Create a job with the input and the user who requested it
• Run the API call in a background worker with a timeout
• Store the result and the token usage with the job
• Notify or refresh the editor's screen when it is ready

Many AI features are asked the same thing repeatedly: a summary of the same article, alt text for the same image, a translation of the same paragraph. Paying for each request is wasteful. Build a cache key from a hash of everything that affects the output, including the model name, the prompt template version, the settings and the input text, and store the result against it.

Before calling the provider, look the hash up. If a result exists and is still valid, return it immediately. When you change the prompt template, change its version so old results are not reused for the new prompt. Transients work for short-lived results; for anything you want to keep, store it with the post so it is backed up and easy to review.

Costs grow through three routes: long inputs, long outputs and too many requests. Limit each one. Trim input to what the task needs, set a maximum output length on every request and rate-limit each user and each IP address for any feature visitors can reach.

Record the token usage the provider returns with each job, and keep a running monthly total. When the total reaches a threshold, alert the site owner; when it reaches a hard cap, stop accepting new jobs and show a polite message. Set a spending limit in the provider's dashboard as well, so a bug in your own accounting cannot produce an unlimited bill.

Model providers have outages, rate limits and slow periods like any other API. Set explicit timeouts on wp_remote_post, treat 429 and 5xx responses as retryable with an increasing delay, and stop after a few attempts. Mark the job as failed with a readable reason so an editor knows what happened.

Design the feature so the site still works without it. If summaries cannot be generated, show the article without one. If a chatbot is unavailable, show the contact form. Never let a failed AI call block checkout, enquiries or publishing.

Language models produce fluent text that can be wrong, outdated or inappropriate for your brand. On a business site that is a reputational and sometimes legal risk, especially for product claims, prices, health information or anything that sounds like advice. Treat generated text as a draft.

Save AI output as a draft, a pending revision or a suggestion field that an editor must accept, and record who approved it. For customer-facing chat, limit the assistant to approved content, make clear that it is automated and offer a route to a person. Guard against prompt injection by never giving the model authority to take actions on its own and by treating its output as untrusted input. The third-party API integration guide and the custom REST endpoints guide cover the WordPress side, and the AI API integrations service explains how I scope these features.