You can now render any curated library template by ID without first
forking it into your account. POST /api/v1/render with
{"templateId":"invoice-classic","data":{...}} works for every caller
— Bearer-token, session, or x402 wallet — and bills the same way as a
saved template.
Behind the scenes, the curated library and your saved templates now
live in the same templates table, distinguished only by ownership.
That collapses the API surface: /api/v1/library is gone, and
/api/v1/templates covers both. List your own with
?owner=mine, browse the library with ?owner=library, or hit the
default to see everything you can read. GET /api/v1/templates/:id
returns either kind, and PUT / DELETE continue to require ownership
(library rows are read-only — they're seed-managed).
The MCP toolset shrinks to match: list_library and
get_library_template are removed, and list_templates /
get_template cover both surfaces. A new owner filter on
list_templates lets agents narrow to library candidates without a
separate tool call.
If you were following the documented "fork-then-render" recipe in your
client code, you can drop steps 1–3 and call /api/v1/render directly
against the library templateId. Forking is still useful when you want
to customise the DSL — pull, edit, POST /api/v1/templates, render
your copy.