Reading WordPress REST Post Fields With the Right Expectations

A WordPress REST API post record answers five useful automation questions: What state is the post in? When was it published? What identifies it? Where does WordPress say it lives? Which media record is featured?

The fields status, date, slug, link, and featured_media provide those answers. They are metadata, however—not evidence that a visitor can reach the page, see the expected theme output, or download an image. Those outcomes require separate checks.

Testing note: This is a documentation-based explanation. No live WordPress site, API response, page, theme, cache, URL, or media file was tested. All JSON values and request paths below are illustrative.

Five fields at a glance

These definitions come from the official WordPress REST API Posts reference.

status: the post’s named state

WordPress defines status as a named post status. The documented values are publish, future, draft, pending, and private (Posts reference).

{
  "id": 42,
  "status": "publish"
}

An automation reading this illustrative response can record that WordPress reports publish. It should not translate that value into “an anonymous visitor can open this page.” The schema defines post state, not the result of an access, routing, HTTP, or rendering check.

date: publication time in the site’s timezone

The date field is the publication date expressed in the WordPress site’s timezone. It is documented as a datetime string or null (Posts reference).

{
  "date": "2026-09-28T14:30:00"
}

Do not automatically interpret this value as UTC. WordPress provides a separate date_gmt field for the publication date as GMT (Posts reference).

Use date when the required fact is the site-local publication timestamp. It does not record when an external visitor first obtained the page, so an automation concerned with observed availability needs a separate live check.

slug: identity within a post type

WordPress defines slug as an alphanumeric identifier unique to the post’s type (Posts reference).

{
  "slug": "building-a-sensor-dashboard"
}

The phrase “unique to its type” sets an important boundary: the documentation does not promise global uniqueness across every resource type. It also does not define the slug as a complete permalink.

Use the slug as a type-scoped identifier. Do not assume that joining a domain and slug will reproduce the correct address; WordPress exposes a separate link field for the post URL.

link: the URL WordPress supplies

The link field is the URL to the post. It is documented as a read-only string in URI format (Posts reference).

{
  "link": "https://example.com/articles/building-a-sensor-dashboard/"
}

This field removes the need to construct an address from the slug. Its presence does not report an HTTP status, redirect chain, access result, canonical destination, cache state, or rendered content. Request the URL when reachability or redirects matter; inspect rendered output when visible presentation is the actual requirement.

Do not confuse link with _links. The _links object maps relationships to API resources, with documented examples including a post’s collection and author (Linking and Embedding).

featured_media: a media ID, not an image URL

The featured_media field contains the integer ID of the post’s featured media item (Posts reference).

{
  "featured_media": 917
}

To obtain the original attachment-file URL, retrieve the corresponding media record:

GET /wp-json/wp/v2/media/917

The media endpoint supports retrieving a media item by ID, and its source_url field is the URL to the original attachment file. The media schema also defines properties such as alt_text, caption, media_type, mime_type, and media_details (Media reference).

That lookup provides media metadata, not proof that the underlying file is reachable or displayed by a theme. The official field definition also does not specify a sentinel meaning for a value such as featured_media: 0; do not assign one without additional evidence.

Missing fields: inspect the request first

A missing property does not necessarily indicate missing post data. The request’s context determines which fields can appear, and the Posts endpoint lists view, embed, and edit contexts (Posts reference).

The global _fields parameter can intentionally restrict a response to selected properties:

/wp-json/wp/v2/posts?_fields=id,status,date,slug,link,featured_media

WordPress says _fields skips unneeded fields while generating the response, producing JSON that requires less transfer and parsing work (Global Parameters). Before interpreting an absent field, therefore, check the _fields selection and request context. Where protected operations are involved, also check authentication and user capabilities; WordPress requires the current user to have the appropriate capability for the action being performed (Authentication).

Embedding related resources

The _embed parameter can request eligible related resources under _embedded. Only links marked embeddable qualify (Linking and Embedding). The official documentation does not guarantee that featured media will be embedded in every post response, so direct retrieval through /wp/v2/media/<id> remains the documented route for requesting a media item by ID.

When combining _embed with _fields, include both _links and _embedded in the selected fields (Global Parameters):

?_embed&_fields=id,featured_media,_links,_embedded

A practical verification ladder

Match each check to the question being asked:

1. Post record: Read status, date, slug, link, and featured_media for documented metadata.
2. Related resource: Retrieve the media record when attachment metadata or source_url is needed.
3. HTTP behavior: Request the post or media URL when the decision depends on reachability or redirects.
4. Rendered presentation: Inspect the page when the requirement concerns visible content, theme output, or featured-image presentation.

The five post fields are reliable descriptions of their documented API values. The key is stopping at what each value establishes—and adding the next check only when the automation needs a fact beyond the record.

Sources and further reading

• https://developer.wordpress.org/rest-api/reference/posts/
• https://developer.wordpress.org/rest-api/using-the-rest-api/linking-and-embedding/
• https://developer.wordpress.org/rest-api/reference/media/
• https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/
• https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/