Validate a .flow source without saving it
Parses and analyses a .flow source against this organization's
segment, template, topic and attribute names, and stores nothing. This
is the cheap authoring loop: every finding comes back with its line
and column, so a mistake is a one-shot fix rather than a guess.
Always 200, including for a source that does not parse — "is this
valid" is the question, and valid: false is an answer rather than a
failure. triggers says what the definition would enrol on, and
send_steps counts its steps that send email or call a webhook at any
depth, which is the number that decides whether activating it forces the
send-approval gate. Both are null when the source did not compile.
Sits on api.workflows.view rather than the manage scope: linting a
source the caller already holds changes nothing, and an author drafting
in CI should not need the permission that can arm a live journey.
Request body
Content type: application/json
source string required The .flow text to check. Nothing is stored.
Responses
Errors follow the RFC 7807 problem format — see the error reference.
valid boolean required diagnostics array<object> required Every finding, with its position. [] means "checked, nothing found".
Each entry in diagnostics:
line integer | null optional column integer | null optional severity string required error blocks the definition from running; warning does not.
message string required triggers object | null optional Null when the source did not compile — there is no AST to walk.
send_steps integer | null optional How many steps that send email or call a webhook the definition contains, at any depth — send and call webhook statements both count, because both reach outside SendOps on a contact's behalf. This is the number that decides whether activating it forces the send-approval gate, so a caller can tell before arming anything. Null when the source did not compile.
validation_failed Problem. When the refusal is about a
reference — a segment key, template slug, topic or attribute name the
organization does not have — it additionally carries validation_code,
field, line/column, missing, candidates and next_step, so a
client can correct the call without a second round of guessing. See
ValidationProblem.
application/problem+json code is internal_error. The
request_id field can be quoted to SendOps support to investigate.
application/problem+json