weelkit-custom-publishing.v2 — lets your API behave exactly like an official CMS integration. Your API declares a bounded manifest describing its content types and capabilities; Weelkit discovers it, an administrator maps fields exactly as they would for WordPress.com or Ghost, and Weelkit publishes canonical semantic HTML with a stable operation identity and structured receipts.
How it fits together
1
You declare a manifest
Your API serves a small JSON document — the manifest — declaring its destination identity, capabilities, content types with typed field schemas, endpoints, and status vocabulary.
2
Weelkit discovers it
Weelkit fetches the manifest over HTTPS, validates it against the protocol’s allowlist and limits, and computes a schema fingerprint.
3
An administrator maps fields
The discovered fields appear in the same mapping review used for official CMS providers. Discovered fields are suggestions — nothing enters the active generation contract until an administrator saves the mapping.
4
Weelkit publishes
Articles are sent from the editor to your declared publish endpoint with a stable operation identity, and your responses are parsed as structured receipts. See Publishing.
5
Weelkit follows each item
Through your readback endpoint, Weelkit follows each item’s status and public URL, so the article shows Published once it’s live on your side. See Status and readback.
What Weelkit asks your API to do
Your API never calls Weelkit. Weelkit reads status from your readback endpoint, so there is no callback to build or authenticate. Requests carry your API key and are not signed; the API webhook is the signed alternative.
What the protocol is not
This is not arbitrary OpenAPI ingestion. Weelkit does not read your OpenAPI specification, crawl your API, or accept free-form schemas. Everything is allowlisted and bounded: field types come from a fixed allowlist, every string has a length limit, the manifest has a size and depth cap, and endpoints must be same-origin paths.
Reference pages
Manifest
The full manifest schema with a worked example.
Authentication
API keys, headers, and transport requirements.
Schema and limits
Allowed field types, every bound, and schema-drift handling.
Publishing
The requests your API receives and the receipts it must return.