Skip to main content
Weelkit’s canonical article catalog — title, main body, excerpt, slug, SEO fields, and the rest — is immutable. An organization controls its article contract in two ways:
  • Default fields — every optional catalog field carries an organization-level switch. Disabled fields are excluded from future article generation. Title and the main article body are structural and always included.
  • Custom fields — organization-owned extensions of the catalog: you define them once, and every article your organization generates from then on is produced against the enabled default fields plus your active custom fields.
Custom field values are resolved with the article, validated against the field definition, and persisted on the exact generated article version. Text and scalar values can be generated; asset and reference fields are resolved by Weelkit. They appear in webhook payloads under article.customFields.
Organization custom fields never reach a CMS destination unless an administrator explicitly maps them in that destination’s field mapping. See Publishing integrations overview.

​
Default fields

Each optional default field — excerpt, slug, meta title, meta description, cover image, categories, tags, and Open Graph title/description/image — can be enabled or disabled for the organization:
  • Disabling affects future generation only. Articles that already carry a value keep it; nothing is rewritten.
  • Title and Main body cannot be disabled. They are structurally required by every article and every destination.
  • Toggles are revision-guarded. Like custom-field edits, each toggle carries the revision it was based on; a concurrent change by another administrator is rejected instead of silently overwritten.
  • CMS mappings show it. In a CMS field mapping, a default field that’s turned off shows as Disabled under Article fields.

​
Field definition

In Organization settings → Article Fields, an administrator chooses Add field and fills in the Label, Field type, whether it’s Required for every article, a Description, a Generation instruction and a Default value, then chooses Create field. Weelkit assigns the field’s stable identifier automatically; nobody needs to create or manage a technical key.

​
Types

The type is chosen from an allowlist and is immutable after creation.

​
Options, labels, and instructions

If a number says Weelkit cannot preserve this number exactly., Save is blocked. A previously stored default stays visible for correction; Weelkit does not round it silently. The generation instruction tells the article generator how to fill model-owned fields. Keep it specific: “One sentence naming the campaign this article supports” produces better values than “campaign info”. Asset and reference types do not accept generation instructions because their identities must be resolved by Weelkit.

​
Defaults

A default value is optional for supported scalar types. When set, it is validated against the field’s type — and, for single- and multiple-choice fields, against the field’s options. Asset, reference, structured, and list types do not accept arbitrary defaults. An invalid default is rejected at save time.

​
Limits and lifecycle

An organization can have at most 24 active custom fields. Turn off (deactivate) fields you no longer generate to free capacity.
A custom field can be deleted from its row menu. Deleting is permanent for the whole organization. A field that a CMS mapping still uses can’t be deleted until it is taken out of that mapping; the message names the mapping. Default fields can only be turned off.
Every save carries the revision it was based on. If another administrator changed the field set in the meantime, your stale edit is rejected instead of silently overwriting theirs. Reload, review, and save again.
After a field is created, its type cannot change. Its name, description, generation instruction, options, and default remain editable within their bounds.

​
Effective contract fingerprint

The organization’s selection is summarized by a deterministic fingerprint on the article output contract:
  • Untouched organization (all recommended defaults enabled, no custom fields): plain weelkit-platform-article.v3.
  • With disabled default fields: a +sel.<16 hex> segment is appended — for example weelkit-platform-article.v3+sel.0123456789abcdef.
  • With active custom fields: a +org.<16 hex> segment is appended — for example weelkit-platform-article.v3+org.abcdef0123456789.
  • Both can combine: weelkit-platform-article.v3+sel.<16 hex>+org.<16 hex>.
The fingerprint appears in webhook payloads as contract.schemaFingerprint, so a consumer can detect exactly which contract a given article version was generated against.

​
Where values appear

  • Values persist on the exact generated article version. Editing the field definition later never rewrites values already generated.
  • Webhook deliveries include the values under article.customFields, keyed by field key:
For the full envelope, see Webhook payload.