Black Friday Sale is Live: Get up to 30% OFF RankReady Pro - the WordPress AI SEO pluginBlack Friday Sale is Live: Up to 30% OFF Get Deal
Features

ACF and custom post types with Hatch

Expose ACF field groups and custom post types to your headless Astro frontend, and use the Hatch checkers that flag anything hidden from the REST API.

Last updated October 29, 2026

By the end of this guide your custom fields and custom post types will be visible to your headless Astro frontend, and you will know how Hatch Connect warns you when one is hidden from the REST API.

What Hatch does and does not do

Hatch does not copy field data itself. ACF and Meta Box already share fields through the WordPress REST API. What they do not do is warn you when a field group is accidentally hidden from REST. Hatch adds that safety net, and does the same for custom post types (CPTs).

Supported plugins

Custom fields, in priority order when more than one is active: ACF Pro, ACF (free), Secure Custom Fields, Meta Box, Pods.

CPT managers, in priority order: CPT UI, Jet Engine, Pods.

When no custom-fields plugin is active, the field checker does nothing.

The field group checker

Hatch scans every field group and reports how many are exposed to REST. Results are cached and available at /wp-json/hatch/v1/acf-status (admin only). It stays empty until you create a field group and turn on “Show in REST” for it.

  1. In ACF, open your field group.
  2. Under the group settings, switch on Show in REST API.
  3. Save the group.
  4. Open a post that uses the group at /wp-json/wp/v2/posts/{id} and confirm the fields appear.

The custom post type scanner

The most common silent failure in headless WordPress is a CPT registered without show_in_rest => true. It looks fine in wp-admin, but the frontend gets a 404. Hatch scans all registered post types (skipping WordPress core types) and flags any that are invisible to REST. The scan is cached for five minutes and refreshed when a post type is registered. Results are at /wp-json/hatch/v1/cpt-health (admin only), and Hatch shows a dismissible notice in wp-admin.

  1. Register your CPT, for example in CPT UI.
  2. In CPT UI, set Show in REST API to true for that post type.
  3. Save. Once it is in REST, the frontend can read its posts at /wp-json/wp/v2/{slug}.
  4. If you register CPTs in code, add 'show_in_rest' => true to register_post_type().

Common problems

  • Fields missing from REST responses. The field group has “Show in REST” turned off. Turn it on and save.
  • Custom post type returns 404 on the frontend. The post type is not in REST. Check /wp-json/hatch/v1/cpt-health and fix the flagged type. If every REST address returns 404, the cause is usually permalinks instead.
  • The notice is still showing after a fix. The scan is cached for a few minutes. Reload wp-admin after a short wait.

Check it in the Hatch admin

  1. Open Hatch in wp-admin and go to the Plugins tab.
  2. Confirm your field plugin and CPT manager show as detected.
  3. Open /wp-json/hatch/v1/features and look at integrations.custom_fields and integrations.cpt_manager. Each shows the plugin slug, or none.
The Hatch Plugins tab with the Custom Fields and Custom Post Types rows in the plugin connections list
The Plugins tab shows which field plugin Hatch is reading from.
The Hatch Content tab with the WordPress settings the frontend uses
Custom post types are shared with the frontend along with posts, pages and menus.

Detection is not the same as data

A green check means Hatch sees the plugin. Fields and CPTs only reach the frontend once they exist and are exposed to REST.

What to do next