Code and core Headless Fast API - Standalone, cacheable REST endpoints that skip the core load cycle

No. The built-in REST API is untouched and keeps working. This plugin adds its own endpoints under /code-and-core-headless-fast-api/v1/.

Individual items use the same field names and structure (title.rendered, content.rendered, featured_media, _links, …), plus acf and yoast_head_json when those integrations are on. Lists are wrapped in an object with count, total, total_pages and data, instead of a bare array with X-WP-Total headers. Content is returned as stored, with paragraphs added. Shortcodes and blocks are not run through the_content filters, because the theme and most plugins have not loaded yet. Render dynamic blocks on your front end, or use the core REST API for the few requests that need them.

Yes. Turn on the ACF integration under Integrations. Fields, repeaters, groups, flexible content, images and options pages are supported, and relationship fields can be expanded with resolve rules.

Yes. With the Yoast integration on, items include yoast_head and yoast_head_json, built from Yoast's indexable data.

Yes. On the Schema screen, open the Custom Fields tab and add the meta key, its type (string, integer, boolean or JSON) and whether it holds a single value.

If disk caching is on, responses are kept for up to an hour. Save the settings with Clear Cache on Save turned on to clear the cache at once. Also check any CDN or proxy cache in front of the site.

Make sure it is public and turned on under Entities, then save. The endpoint name is the post type or taxonomy name with an s added (for example product becomes products). Categories, tags, pages and media use categories, tags, pages and media.

Check that permalinks are not set to "Plain", and that the URL contains /code-and-core-headless-fast-api/v1/.

No. Requests reach the API through WordPress's normal permalink handling on every server.

Fast Mode cannot be turned on, and the plugin tells you so. The API keeps working and returns identical responses; it is answered on plugins_loaded instead, which is slower on sites with many plugins.

Data that plugins save to the database is included. Output that plugins add at runtime through filters is not, because those plugins do not load on API requests in Fast Mode. If you need that output, leave Fast Mode off.

Yes. Use Download Backup under Advanced on the first site, then Restore on the second.

Each site has its own uploads folder, so each site keeps its own configuration and cache. Fast Mode checks both site-level and network-wide activation.

Every list is in data, with totals beside it: const API = 'https://example.com/code-and-core-headless-fast-api/v1'; const json = await fetch(API + '/posts?per_page=6&categories=3').then(r => r.json()); json.data.forEach(post => console.log(post.title.rendered)); In Next.js (App Router), add { next: { revalidate: 60 } } to fetch() to refresh the data every 60 seconds.

• Turn on Fast Mode. It has the biggest effect on sites with many plugins.
• Remove fields you don't use on the Schema screen, for example content on list endpoints that only show cards.
• Use resolve rules instead of requesting related posts, images or terms one at a time.
• Turn on disk caching, and put a CDN in front of the API.
• Keep per_page small and paginate with page and total_pages.

The Code and Core Headless Fast API menu has five screens:

• Dashboard: every endpoint URL, with a request tester.
• Entities: the post types, taxonomies and users to expose.
• Schema: the live response builder, field exclusion, custom meta, and resolve and append rules.
• Integrations: Yoast SEO and ACF.
• Advanced: caching, Fast Mode, and import, export and reset.

The API is public and read-only, like the core REST API for published content. No API key or login is needed. Only the post types, taxonomies and entities you enable are served. Use field exclusion to remove anything your front end does not need.

No. The API is read-only and answers only GET requests. Use the built-in WordPress REST API for writes.

Yes. They are completely separate. Many sites use this plugin for public, read-heavy pages and the core REST API for previews, forms and authenticated actions.

Block content is returned as saved in the database, with the block comment markup and HTML included. Static blocks display correctly. Dynamic blocks (latest posts, query loops, shortcodes) are not rendered on the server, because the theme and most plugins have not loaded yet. Render those on your front end.

Page builders usually render their output through filters at runtime, which do not run here. This plugin works best with content from the block editor, the classic editor and ACF fields. For pages made with a page builder, use the core REST API or build those sections from ACF fields.

Products are a public post type, so products can be turned on under Entities, and the title, content, excerpt, images, terms and selected meta (for example _price or _sku through Custom Fields) are returned. Calculated WooCommerce data such as variations, tax-inclusive prices and stock status is not included. Use the WooCommerce Store API for cart and checkout.

There is no dedicated multilingual integration yet. Translated posts are returned like any other posts, but filtering by language is not available.

Yes. Any public post type or taxonomy appears under Entities, however it was registered. Save once after adding a new one.

By default, only published posts (and attachments) are returned. Use WordPress's own preview tools or the authenticated core REST API for draft previews.

Each post includes featured_media (the attachment ID). To get the full image object in the same response, add a media resolve rule for featured_media on the Schema screen, or request /media/{id}.

First get the term ID from /categories/{slug}, then request /posts?categories={id}. You can also cache the term ID on your front end.

Use page and per_page. Every list response includes total and total_pages, so you can build pagination without reading headers.

Single post responses include pagination.previous_post and pagination.next_post, each with id, title and slug, or null at either end.

Request /home. It returns the static front page set under Settings > Reading, or the latest posts if the front page shows posts.

Open the Schema screen, choose the endpoint, press Send, then switch off fields in the response tree and press Save & Sync Schemas. Exclusions are saved separately for list and single responses.

A resolve rule replaces an ID (or a list of IDs) already in the response with the full object, such as a related post, image, term or user. An append rule adds new data that is not in the item, such as a list of the latest posts, under a field you choose.

Up to one hour, as JSON files in wp-content/uploads/code-and-core-headless-fast-api/cache/. Each unique URL, including its query string, is cached separately.

Yes, and it is recommended. Responses are public, cookie-free GET requests with a JSON content type, which makes them easy to cache at the edge.

Check the X-HeadlessFastAPI-Cache response header. It is HIT when the disk cache answered and MISS when the response was built.

Yes. Every response sends Access-Control-Allow-Origin: *, so browsers on any domain can call the API without a proxy.

No. The Fast Mode file acts only on URLs that contain /code-and-core-headless-fast-api/v1/. Every other request, including the admin, the front end and the core REST API, loads exactly as before.

Yes. It is listed under Plugins > Must-Use as "Code and Core Headless Fast API - Fast Mode". Turn it off from the plugin's Advanced screen, not by editing the file.

Yes. Page-caching plugins may also cache the API URLs, which is fine for public content. If a security plugin blocks unfamiliar URLs, allow the /code-and-core-headless-fast-api/v1/ path.

Yes. The plugin works with or without a persistent object cache. Its own response cache is separate and stored on disk.

Yes. Settings are stored in the uploads folder and are not touched by updates. The Fast Mode file is rewritten for the new version automatically.

WordPress 6.0 or later, PHP 7.4 or later, MySQL or MariaDB, and permalinks set to anything other than "Plain". Write access to the uploads folder is needed for settings and caching, and to wp-content/mu-plugins for Fast Mode.

Use the plugin's support forum on WordPress.org, or contact Code and Core through https://codeandcore.com. Please include your WordPress, PHP and plugin versions and the endpoint URL you are calling.

Deactivating removes the Fast Mode file and stops the API. Deleting the plugin also removes its options and its wp-content/uploads/code-and-core-headless-fast-api/ folder.