WordPress wp_remote_retrieve_body Example: Parse HTTP Responses Safely

Last reviewed: May 16, 2026

When WordPress code calls an external API, the raw response array is only the start of the job. The next step is usually extracting the body safely and handling failure branches before JSON decoding or downstream parsing begins. wp_remote_retrieve_body() is the helper WordPress provides for exactly that body-extraction step.

This guide shows how to use wp_remote_retrieve_body() in a clean HTTP workflow, why it belongs after an explicit error check, and how it keeps response handling easier to read than direct array access.

Check the HTTP call first, then retrieve the body

<?php
$response = wp_safe_remote_get( $endpoint, $args );

if ( is_wp_error( $response ) ) {
	return $response;
}

$body = wp_remote_retrieve_body( $response );
$data = json_decode( $body, true );

This is the right sequence. The code does not assume a successful transport, and the body retrieval stays a simple extraction step rather than a hidden error handler.

Do not treat body extraction as response validation

wp_remote_retrieve_body() returns the body string. It does not confirm that the upstream service returned a useful status code, valid JSON, or the payload shape your integration expects. Production HTTP clients still need status-code checks and parsing guards after the body is retrieved.

Prefer the helper over manual array indexing

Using the WordPress helper keeps the intent clear and matches the rest of the HTTP API style. Reviewers immediately know that the code is retrieving the response body, not digging through a transport-specific structure by hand.

Common mistakes

• Skipping the is_wp_error() guard before reading the response. Transport failures still happen.
• Assuming a body means the request succeeded semantically. Check status codes too.
• Indexing directly into the response array. The helper is clearer and less brittle.
• Decoding JSON without handling invalid payloads. Body extraction is not parse validation.

Production checklist

• Check for WP_Error before reading the response body.
• Use wp_remote_retrieve_body() instead of manual array access.
• Review the response code before assuming the payload is usable.
• Guard JSON decoding and payload-shape assumptions separately.
• Keep logs and retry logic focused on the right failure layer.

Related reading

Pair this with the wp_safe_remote_post guide for a closely related HTTP request workflow and with the is_wp_error article so transport failures are handled before payload parsing begins.

References and further reading

• WordPress Code Reference: wp_remote_retrieve_body()
• WordPress Common APIs Handbook: HTTP API
• WordPress Code Reference: wp_safe_remote_get()