Recipes

A recipe is one task from start to finish: the calls in the order you make them, the response each one really returns (shortened), and a check at the end that tells you it worked. The reference pages explain every field; recipes only show the path through them.

All examples assume two shell variables from the quickstart: $OP_TOKEN with your personal op_ token and $BASE with the API v2 base URL. The site is chosen with blog_id in the body or the X-OnPress-Blog-Id header, as described in authentication.

Recipes

• Create a page — publish markdown into a section, read the response, update the same page, go from draft to published and place it in the docs tree.
• Shell with header and footer — upload site__header, site__footer and an article shell that pulls them in, then put a page into it.
• FAQ from data — one faq dataset for the whole site, filtered per page, with FAQPage schema and no block on pages without questions.
• Translate a page — publish a translation with translation_of, check the group, link existing pages, translate datasets and menus.
• Upload an image — put a file into the media library by URL or as base64, insert it into markdown and set the site icon.
• Rename a frame — move an old transliterated slug to block__element naming without breaking the frames and pages that use it.

Before you start

Every write in these recipes is real. Where an endpoint supports dry_run, the recipe shows it first: the answer has the same shape as the real write, with "applied": false, and nothing is stored. Endpoints without dry_run (media uploads, frame renames, translation groups) are safe to repeat or fail before writing anything; each recipe says which.

Errors come back as {"success": false, "error": "<code>", "message": "…"}; branch on error. The full list is on the errors page.