Introduction
What OnPress v2 is, which entities it is built from, the one development rule, and how API v2 relates to API v1.
OnPress v2 is a site platform on multisite WordPress whose workplace is an API, not wp-admin. A person states the task; an agent publishes pages, uploads markup and changes the look with requests. v2 was designed for that consumer: the expected client of API v2 is an agent, and wp-admin is legacy that everything moves out of as soon as an endpoint for it exists.
Three entities, plus data
A page is markdown. Frontmatter carries what v1 kept in metaboxes — name, slug, path in the tree, language, SEO fields, excerpt, the page’s frame; the body is converted into Gutenberg blocks. Nobody opens the editor, and nobody needs to. See Pages and markdown and Markdown syntax.
A look is a frame. Ready-made markup uploaded as it is: an article shell, a header, a footer, an FAQ block, a whole landing page exported from a builder. Nothing in it is rewritten or sanitised — an inline <script> survives byte for byte. A page is bound to exactly one frame; frames pull in other frames by name with op/frame. Dynamic parts are inserts (op/menu, op/content, op/repeat and the rest) and bindings (data-op-bind). See Frames.
Styling is design tokens and custom CSS. A closed set of named values with defaults from the theme, plus one free-form stylesheet on top. Both are read and rewritten by request. See Styles.
Data is what repeaters print. Your own datasets (an FAQ, footer columns, a list of links) with language variants, and system sources the platform computes itself — menus, languages, child pages, breadcrumbs. A frame never hard-codes a list; it repeats over a source. See Data.
Everything else — hand layout in the editor, ad-hoc ACF layouts, menu builders — is not part of v2 and stays as v1 legacy.
The rule: only through an endpoint
Every operation on the platform is done through an API endpoint, not by hand. If there is no endpoint, the endpoint is written first and the work is done with it. The result of a task is the endpoint plus its call, not a changed state of a site: state created around the API cannot be reproduced, cannot be repeated on another site and cannot be checked with the same API that made it.
For you as a reader this means one thing: if something here says “go to wp-admin”, that is a gap still to be closed, not a way of working.
Two APIs side by side
OnPress runs two API contours at once. They do different jobs, and since the token change they share one credential.
| API v1 | API v2 | |
|---|---|---|
| Base URL | https://<site>/wp-json/onpress/v1/ | https://stagepress.bond/api/v2/ |
| Implemented in | PHP, inside WordPress | Node.js, writes to the database without booting WordPress |
| Credentials | Application Password (Basic) or the op_ token | the op_ token only |
| Network site | the site’s domain in the URL | blog_id or domain in the request |
| Covers | legacy: apps, mail, sites list, page tree for the dashboard, token issuing | frames and rebaking, data, design tokens, CSS, menus, docs sidebar, markdown publishing, page language, translations, media, sites and settings |
The op_ token opens both: v1 accepts it through the adapter in the onpress-api-keys mu-plugin, and the dashboard works with v1 and v2 on one token. The Application Password stays for v1 and for one more job — issuing the first token without a browser. Details are in Authentication.
Where things are stored
Frames, datasets, custom CSS and design tokens live in the options of the one network site they belong to. There are no network-wide options, deliberately: the staging environment shares its database with the production sites, and a network option would roll out to the whole network at once. The same fact explains why every request names its site — without blog_id or domain the request goes to blog 1, the main production site. More in How it works.
Where to go next
Quickstart takes you from nothing to a published page. How it works explains baking, rebaking and who does what between Node and PHP. The API reference lists every endpoint, and Recipes solve typical tasks end to end.