Thrive Architect exposes your page content through the standard WordPress REST API (for reading structured meta) and a Thrive-specific write endpoint (for saves that match the editor pipeline), so you can connect AI assistants (Claude, ChatGPT, and others), IDE agents (Cursor, Claude Code), content pipelines, and custom scripts without changing how you work inside the editor.
This article explains what is supported today, exact routes and fields, how reading differs from writing, and how to keep your site secure when enabling programmatic updates.
What you can do
Read Thrive Architect content (REST API content access)
External systems can read Thrive Architect–built content for posts and pages that use the editor. Architect stores layout HTML and related settings in post meta; those keys are registered on the core wp/v2 post type endpoints so they appear under meta in JSON responses.
Typical uses: reporting, migrations, backups, AI summarization or rewriting, diffing layouts, and integrations that need a structured copy of your layout data.
Implementation reference (codebase): tcb/inc/rest-meta.php — registers read-only meta on rest_api_init. Custom post types can be added with the WordPress filter tcb_rest_meta_post_types (defaults: post, page only).
Save Thrive Architect content programmatically (REST API content saving)
Trusted tools can save Architect content with POST requests to the Thrive endpoint below. This path is parity-equivalent to the editor’s save pipeline (TCB_Editor_Ajax::save_post_content()), including the same hooks and side-effects as admin-ajax saves.
Implementation reference (codebase): tcb/inc/classes/rest/class-tcb-content-rest.php — namespace tcb/v1, route POST /posts/{id}/content.
Writes are not accepted via wp/v2/posts / wp/v2/pages meta updates; use the dedicated endpoint only.
Reading content
Base URL
Use your site’s REST API root (usually):
https://your-domain.com/wp-jsonEndpoint (posts and pages)
| Goal | Method | URL pattern |
|---|---|---|
| Read a post with Architect meta | GET | /wp/v2/posts/{id} |
| Read a page with Architect meta | GET | /wp/v2/pages/{id} |
Optional query parameters:
- ?_fields=id,slug,status,title,meta — smaller payloads for agents.
- ?context=edit — when you are authenticated and need fields that WordPress only exposes in an editing context (useful for some workflows alongside edit_post).
Authentication
- Published, public content: unauthenticated GET may be enough for public fields; Thrive meta on non-public posts (draft, private, pending, password-protected) is hidden unless the caller can edit_post on that post (defence-in-depth in tcb_rest_meta_hide_for_non_public).
- Drafts or member-only workflows: use Application Passwords or another authenticated mechanism so WordPress can authorize the request.
Meta keys you will see under meta
These are the Thrive Architect fields exposed for read via REST (shape is JSON as returned by WordPress):
| Meta key | Purpose |
|---|---|
| tve_updated_post | Canonical Architect HTML for the layout (main content source for editor-built pages). |
| tve_custom_css | CSS rules generated by the editor (inline rules storage). |
| tve_user_custom_css | User-authored custom CSS for the post. |
| tve_globals | Page-level settings object (fonts, lightbox refs, etc.). |
| tcb2_ready | 1 when content is on the TCB2 format. |
| tcb_editor_enabled | 1 when Architect is enabled for this post. |
| tve_landing_page | Landing page template key, if applicable. |
| _tve_header | Custom header symbol id, if set. |
| _tve_footer | Custom footer symbol id, if set. |
Example: read with curl
Replace {id} and credentials as appropriate.
curl -sS 'https://your-domain.com/wp-json/wp/v2/pages/123?_fields=id,title,meta'
-u 'wp_username:your_app_password_here'Successful responses include a meta object containing the keys above when the post is readable and policy allows exposing them.
Example: read with JavaScript (fetch)
const base = 'https://your-domain.com/wp-json/wp/v2';
const id = 123;
const user = process.env.WP_USER;
const pass = process.env.WP_APP_PASSWORD; // Application Password, not the login password
const res = await fetch(`${base}/pages/${id}?_fields=id,title,meta`, {
headers: {
Authorization: 'Basic ' + Buffer.from(`${user}:${pass}`).toString('base64'),
},
});
const data = await res.json();
const architectHtml = data.meta?.tve_updated_post;Saving content securely
Programmatic writes use:
- HTTPS in production.
- WordPress Application Passwords (recommended) on a user that already has permission to edit the target content in WordPress and has Thrive Architect access (the same product capability you use in the dashboard; the REST layer checks tcb_has_external_cap() plus edit_post on the target).
Create an Application Password
- WordPress admin → Users → your integration user → Profile.
- Application Passwords → name it (e.g. Cursor Architect sync) → Add.
- Copy the generated password once; store it in a password manager or server secret (never commit to git).
Write endpoint
| Item | Value |
|---|---|
| Method | POST |
| URL | https://your-domain.com/wp-json/tcb/v1/posts/{id}/content |
| Content types | application/json (recommended) or form-encoded body |
| Auth | HTTP Basic: username + application password |
{id} is the numeric WordPress post or page ID (the same ID you use with wp/v2/posts / wp/v2/pages).
Note: WordPress routes this under the Thrive namespace tcb/v1; it is not a core wp/v2 route.
JSON body fields (high level)
The save pipeline mirrors the editor. Common keys (all optional unless your layout requires them):
| Field | Role |
|---|---|
| tve_content | Full Architect HTML to persist. |
| inline_rules | Editor-generated inline CSS (stored as tve_custom_css meta in the save pipeline). |
| tve_custom_css | User-defined custom CSS for the post. |
| tve_globals | Object with page-level globals (e.g. font classes). |
| tve_stripped_content | Plain-text / simplified content used for post_content migration paths. |
| tve_landing_page | Landing template key or empty for normal content. |
| page_events | Page-level event configuration array, if used. |
| header / footer | Header/footer section ids when applicable. |
| has_icons, tve_has_masonry, tve_has_typefocus, tve_has_wistia_popover | Feature flags as saved from the editor. |
| custom_font_classes | Array of custom font class names. |
You do not need to send update: true; the REST controller forces the rich-content save path.
Invalid JSON with a JSON content type returns 400 (tcb_rest_invalid_json) so malformed agent output cannot blank a post silently.
Example: save with curl
curl -X POST 'https://your-domain.com/wp-json/tcb/v1/posts/123/content'
-u 'wp_username:your_app_password_here'
-H 'Content-Type: application/json'
-d '{
"tve_content": "<div class="thrv_wrapper">...</div>",
"inline_rules": "",
"tve_custom_css": "",
"tve_globals": {},
"tve_stripped_content": "Short plain summary for SEO/excerpts if needed."
}'The response body matches the internal save result (e.g. includes success); HTTP status is 200 on success and 500 when the save pipeline reports failure—inspect the JSON and server logs.
Why writes do not go through wp/v2/…?meta=
Core post endpoints are intentionally blocked from accepting Thrive meta writes (auth_callback on each field plus rest_pre_insert_* stripping). Always use POST /wp-json/tcb/v1/posts/{id}/content for programmatic layout saves.
Using with AI tools (Claude, ChatGPT, other APIs)
Pattern that works well across tools:
- Read — GET wp/v2/posts/{id} or wp/v2/pages/{id} and read meta.tve_updated_post (and related meta as needed).
- Transform — your AI step produces updated HTML/CSS according to your rules.
- Write — POST the full payload your workflow needs to /tcb/v1/posts/{id}/content with Application Password auth.
Operational tips:
- Staging first — have the agent work against a staging site or a copy of the post until you trust the HTML round-trip.
- Preserve structure — arbitrary HTML from a model may strip Thrive-specific classes or wrappers; safest workflows start from a copy of existing tve_updated_post and apply targeted edits.
- Secrets — pass Application Passwords via environment variables or your host’s secret store; never hard-code in prompts that get logged externally.
Cursor (or other IDE agents)
Typical setups:
- Store WP_BASE_URL, WP_USER, WP_APP_PASSWORD, and optional WP_POST_ID in .env (gitignored).
- Give the agent a small script (Node, Python, or PHP) that performs GET/POST using those variables, or connect a WordPress MCP server if your workspace uses one—under the hood it still uses REST with whatever auth that server configures.
- Ask the agent to only call your script or documented curl commands so credentials stay out of the chat transcript where possible.
Claude (claude.ai, API, or Claude Code)
Same integration pattern: either curl from a terminal skill, a minimal Python/Node client, or orchestration via make.com / n8n / custom middleware that holds the Application Password and forwards model output to POST /tcb/v1/posts/{id}/content.
Rate limits and safety
- Respect normal WordPress and hosting rate limits; batch large jobs with delays.
- Rotate Application Passwords when a team member leaves or a token may have leaked.
Permissions and errors (quick reference)
| Situation | Typical HTTP result |
|---|---|
| Not logged in / no valid Basic auth | 401 |
| User lacks Thrive Architect product capability | 403 (tcb_rest_no_architect_cap) |
| User cannot edit_post on target | 403 |
| Invalid post id | 400 / 404 depending on case |
| Post type not editable with Architect | 400 |
| Malformed JSON body (JSON content type) | 400 |
What does not change
- Editing in Thrive Architect is unchanged.
- Existing manual publishing and editor saves behave as before.
- Treat API credentials like production passwords; use writes only from trusted automation.
Related documentation
- Extending Thrive Themes Capabilities as a Developer
- How to Add Custom Integrations Using Webhooks in Thrive Architect
- WordPress handbook: Application Passwords
WordPress handbook: REST API reference