With Statamic 6.31.0, you can point a tool at the REST API and let it discover the site's collections, taxonomies, navs, asset containers, and locales for itself.

Without hard-coded resource handles, the same headless frontend, add-on, or integration can connect to different Statamic sites and build around the resources each one exposes. Build a content explorer or search indexer once, then let each site show it around.

Give your tools a map

Start by checking that the API is awake:

GET /api/ping

{ "ping": "pong" }

/api/ping is available whenever the REST API is enabled, regardless of which content resources are enabled. That gives connection screens, health checks, and setup wizards a reliable place to begin.

From there, a tool can ask what the site contains:

GET /api/sites
 
GET /api/collections
GET /api/collections/blog
GET /api/taxonomies
GET /api/taxonomies/tags
GET /api/navs
GET /api/navs/main
GET /api/asset-containers
GET /api/asset-containers/main

These responses describe the top-level shape of the content model. Collections include their structure and mount information, navs expose their depth and root behavior, and sites include their locales and URLs. Collections, taxonomies, navs, and asset containers also return their handles, titles, and canonical API URLs.

The metadata endpoints respect your existing resource allowlists, so the map only includes roads you've opened. If the API exposes the blog and products collections, those are the collections a tool will discover. Sites remain disabled by default and can be enabled with resources.sites in config/statamic/api.php.

Let the site fill in the blanks

Once a tool has that map, it can build an interface or workflow around the site it actually connected to:

• A content explorer can build its site switcher and resource sidebar from the API responses, then load entries, terms, nav trees, and assets using the discovered handles.
• A search or sync connector can enumerate every enabled collection instead of carrying project-specific handles in its configuration.
• An integration's setup screen can offer real collections, navs, and asset containers in select fields instead of asking someone to type each handle exactly right.

The tool still understands Statamic's standard REST API routes, but it doesn't need to assume your collections are called pages and blog, your nav is called main, or your asset container has the incredibly original handle assets. The site tells it what's available.

Follow the map into content

Discovery gets the tool oriented, and the other REST API updates make the next request much cleaner:

GET /api/collections/pages/entries/about?site=fr&fields=id,title,content

That request combines three useful improvements:

• about can be an entry's slug, so a route-driven frontend can pass along the URL segment it's already handling. The endpoint still accepts IDs, and an ID takes priority if it collides with another entry's slug.
• Multi-site now has a first-class site query parameter. Pass ?site=fr to entries, taxonomy terms, and term entries to request the French site. filter[site] remains supported.
• fields shapes the response on list endpoints as well as individual entries and assets. You can request a small set of top-level fields for an index, then ask for the heavier content when someone opens an item.

The fields parameter accepts comma-separated values or array syntax such as fields[]=id&fields[]=title, which keeps things friendly for HTTP clients that build query strings for you.

Pagination links preserve fields, site, and query_scope. A search indexer or sync process can follow those links while keeping the same locale, payload shape, and query scope all the way through the collection.

Go explore

Statamic 6.31.0 is available now:

composer update statamic/cms

The REST API docs cover the endpoints, responses, and configuration. Start your next integration with the API URL, let the site fill in what it knows, and show us the content explorers, sync connectors, and strange little tools you build from there. 💜