Ironclad "missing required field" error on workflow launch via API

Fix Ironclad "missing required field" on workflow launch via API

TL;DR

Your launch payload is missing a required field, or a field key doesn't match the workflow's launch form schema exactly. Read the workflow configuration's launch form through the API, compare your payload key by key against the required list, fix names and value formats (dropdown options must match exactly), and relaunch.

missing required field

Steps

1. Fetch the workflow configuration including its launch form field schema via the API. Expected: a field list showing each field's key, type, allowed values, and whether it's required.

2. Diff your launch payload against the required fields, checking keys character for character. Expected: you find the missing field or the misnamed key (UI labels and API keys often differ).

3. Fix value formats: dropdowns must use exact option values, dates must use the expected format, numbers must be numbers not strings. Expected: the payload validates against the schema.

4. Re-run the launch. Expected: success response with the new workflow record ID.

Use this when

• A workflow launch API call fails with "missing required field" on a payload that looks complete
• You built the payload from UI labels instead of the API schema
• A workflow was republished with new required fields and your integration broke

Not for this skill when

• The error is "record not found" (that's an ID/environment problem)
• Fields are present but values are rejected (that's a validation/format problem on values)
• The launch succeeds but the workflow misbehaves later (that's a design problem)

Variant phrasings

ironclad api launch validation failed required field

Pull the schema first; don't guess field keys.

ironclad workflow launch form fields api

The launch form schema is part of the workflow configuration resource.

ironclad required field key mismatch

UI display names are not API keys; always use the schema's keys.

Why it happens

Launch form fields are configuration-specific: keys, types, and required flags are defined per workflow, and UI labels rarely match API keys exactly. Integrations built by copying what the form shows a human break the moment a field is renamed or a new required field is added on republish.

Edge cases

• Conditionally required fields only trigger for certain answers; test each branch of the launch form.
• Hidden fields with defaults can still be required by the API; the schema is the source of truth, not the visible form.
• Republish can change keys; re-fetch the schema in CI rather than hardcoding it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BvMWkGJsN0w1jwJLBGDUAg