> ## Documentation Index
> Fetch the complete documentation index at: https://docs.weelkit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom API overview

> Make your own API a first-class schema-backed publishing destination with the Weelkit Custom Publishing API protocol.

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](https://docs.weelkit.com/integrations/custom-api/manifest.md) — 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](https://docs.weelkit.com/integrations/custom-api/schema-and-limits.md), 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](https://docs.weelkit.com/integrations/custom-api/publishing.md).

**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](https://docs.weelkit.com/integrations/custom-api/publishing.md#status-and-readback).

## What Weelkit asks your API to do

| Operation | Request | When |
| - | - | - |
| Discover | `GET` the manifest path | Connecting, **Refresh destination fields**, and before every other request |
| Create | `POST` the publish endpoint, `operation: "create"` | An article is sent for the first time |
| Update | `PUT` the publish endpoint, `operation: "update"` | A sent article is sent again |
| Read | `GET` the readback endpoint | **Verify test draft** and the scheduled status checks |
| List | `GET` the list endpoint | Offering the items a reference field can point to |
| Delete | `POST` the publish endpoint, `operation: "delete"` | **Delete draft** on a failed test draft, if you declare `delete` |

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](https://docs.weelkit.com/integrations/custom-api/authentication.md) and are not signed; the [API webhook](https://docs.weelkit.com/integrations/webhook/setup.md) is the signed alternative.

## What the protocol is not

> [!NOTE]
>
> 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](https://docs.weelkit.com/integrations/custom-api/manifest.md)**
>
> The full manifest schema with a worked example.

> **[Authentication](https://docs.weelkit.com/integrations/custom-api/authentication.md)**
>
> API keys, headers, and transport requirements.

> **[Schema and limits](https://docs.weelkit.com/integrations/custom-api/schema-and-limits.md)**
>
> Allowed field types, every bound, and schema-drift handling.

> **[Publishing](https://docs.weelkit.com/integrations/custom-api/publishing.md)**
>
> The requests your API receives and the receipts it must return.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.