Skip to main content
Everything in the Custom Publishing API protocol is allowlisted and bounded. A manifest that exceeds any limit is rejected at discovery time with a clear validation error — nothing is partially accepted. Text beyond its bound, an unreadable option, a status word outside its alphabet and a flag that is not true or false are limit violations too.

Allowed field types

Any other type value fails validation.

Limits a field can declare

A field may declare constraints that Weelkit enforces before it sends a value. The allowed limits depend on the type: Declaring a limit the type does not support, or a lower limit above its upper limit, rejects the manifest.

Limits

Network boundaries

  • Redirects are never followed — not during discovery, publishing, or readback.
  • Private, loopback, link-local, and cloud-metadata hosts are rejected at connect time. A Custom API destination must resolve to a publicly routable address.
  • The base URL uses HTTPS on the standard port 443, with no credentials, query string or fragment.
  • Weelkit applies a DNS-rebinding defense at connect time, so a hostname cannot pass validation with a public address and later resolve to a private one for the actual requests.

Schema fingerprint and drift

At discovery, Weelkit computes a schema fingerprint of the form custom-api.v2.<32 hex> (for example custom-api.v2.0123456789abcdef0123456789abcdef) over the manifest’s normalized structure. Field labels and descriptions are excluded: renaming a field label never counts as a schema change, while adding, removing, or retyping a field, or changing a declared limit, always does. Weelkit reads your manifest whenever it talks to your API, including the background status checks. A schema change takes effect in the mapping only when an administrator chooses Refresh destination fields. When a refresh produces a changed fingerprint, that is schema drift:
1

Publishing pauses

New dispatches to the destination stop until the drift is resolved.
2

Mapping review required

An administrator reviews the saved mapping against the new schema and saves it again, then chooses Verify test draft. Publishing resumes after verification succeeds.
In-progress generations and persisted contracts never silently change. An article being generated when drift is detected finishes against the contract it started with, and already-persisted article versions keep the contract they were generated under.