etchKit exposes a single read-only REST endpoint. The panel uses it to fetch the library data on first load.

Endpoint #

GET /wp-json/etchkit/v1/components

Returns the full contents of library/library.json as a JSON response.

Authentication #

The endpoint requires a logged-in user with the edit_posts capability. That means editors, administrators, and any custom role with that capability. Contributors and subscribers cannot access it.

Authentication uses the standard WordPress nonce system. The nonce is generated server-side via wp_localize_script and injected into the page as a JavaScript variable. The panel includes it as the X-WP-Nonce header on every request automatically. You do not need to handle this manually unless you are building something that calls the endpoint outside of the panel.

Browser caching #

The response includes two caching headers:

• ETag derived from the library file’s last modification time
• Cache-Control: private, max-age=3600

On repeat visits within one hour, the browser sends If-None-Match with the stored ETag. If the file has not changed, the server responds with 304 Not Modified and no body is transferred. This keeps repeat page loads fast without serving stale data.

Server caching #

After the first request parses library.json, the decoded data is stored in a WordPress transient under the key etchkit_library, alongside the file’s modification timestamp.

On subsequent requests, the server compares the stored timestamp against the current file. If they match, the cached data is returned immediately without reading or parsing the file again. If the file has changed (you edited library.json), the transient is overwritten with the new data. Stale entries never accumulate because the transient is replaced, not abandoned.

Error responses #

The endpoint returns standard HTTP error codes:

• 404 if library/library.json is missing from the plugin directory
• 500 if the file exists but cannot be read or contains invalid JSON