Integrating WordPress with External APIs the Right Way

Sooner or later every serious WordPress build talks to something else: a CRM, a payment provider, a property feed, an internal service. The integrations that cause trouble are rarely the ones with clever logic; they are the ones that call a remote API in the middle of rendering a page and hope the network cooperates. A few patterns, applied consistently, make the difference between an integration and a liability, and the reliable version is barely more code than the fragile one.

Use the HTTP API WordPress gives you

wp_remote_get and wp_remote_post exist so you never touch curl directly. They handle transport differences across hosts, return errors as WP_Error objects you can actually inspect, and are filterable, which matters more than it sounds: request logging, proxying and test mocking all hook in cleanly. Always set an explicit timeout, because the default is generous and a page render should never wait long for anyone else's server. Wrap each service in one small client class so headers, retries and error handling live in a single place instead of being copy-pasted around the theme.

Never fetch during render if you can avoid it

The core pattern for read integrations is fetch, cache, serve. The page reads from a transient; the transient is refreshed when stale; and if the remote service is down, the page falls back to the last known good data rather than failing. Transients ride the persistent object cache when one is present, so the pattern gets faster on exactly the sites that need it most.

$cached = get_transient( 'strcli_rates' );
if ( false !== $cached ) {
    return $cached;
}
$response = wp_remote_get( 'https://api.example.com/rates', array(
    'timeout' => 5,
    'headers' => array( 'Authorization' => 'Bearer ' . STRCLI_KEY ),
) );
if ( is_wp_error( $response ) ) {
    return get_option( 'strcli_rates_fallback', array() );
}
$data = json_decode( wp_remote_retrieve_body( $response ), true );
set_transient( 'strcli_rates', $data, 15 * MINUTE_IN_SECONDS );
return $data;

For data that must always be warm, invert the flow: a scheduled job refreshes the cache in the background and the page only ever reads locally. Visitors then never pay the remote latency at all, and an outage at the provider becomes a staleness problem instead of a downtime problem. Writes go the same way: queue the CRM update or the fulfilment call as a background action with retries, rather than making a customer's checkout wait on a third party.

Treat credentials like credentials

API keys do not belong in the options table, where they travel with every database export and appear in every backup. Define them as constants in wp-config.php or inject them as environment variables, keep them out of version control, and use separate keys per environment so a staging experiment cannot touch production data. When a key must rotate, and eventually one must, configuration-level secrets make it a deployment rather than an archaeology exercise.

Receiving data: webhooks in

Inbound integrations deserve the same rigour. Register a proper REST route rather than a bare PHP file, verify the sender by checking the provider's signature header before trusting a byte of the payload, and respond quickly by storing the event and processing it in the background, because most providers time out slow webhook receivers and retry, which is how duplicate processing sneaks in. Design the handler to be idempotent, keyed on the event ID, and retries become harmless.

Finally, log what crosses the boundary in both directions: outbound request, status and duration; inbound event and outcome. When a provider's support team asks what you sent at 14:03 on Tuesday, the difference between a log line and a shrug is the difference between a ten-minute fix and a week of email. A structured log file is enough; the discipline matters more than the tooling.

The theme across all of it: assume the network fails, assume the provider is slow, and make sure your visitors never find out. Build integrations that degrade instead of break, and third-party incidents become entries in your log rather than your support inbox. STRCLI builds and rescues WordPress integrations regularly; if yours is the fragile kind, we can help.