Skip to main content
The Weelkit Custom Publishing API protocol — protocol version 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.
Manifest text — names, labels, descriptions — is treated as untrusted data. Weelkit displays it to administrators but never interprets it as instructions, never executes it, and strips control characters. Write labels for humans; they cannot change Weelkit’s behavior.

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.