Routing rules

Rules are checked from top to bottom. Each rule combines conditions with all (AND) or any (OR), and a submission is delivered to the destinations of every rule that matches - not just the first. The last rule is always the default: it has no conditions and catches whatever nothing above it matched, so a submission is never silently dropped. It cannot be deleted or given conditions.

Tick Stop here when this matches on a rule to skip every rule below it, including the default, once that rule matches.

Conditions read submitted fields by name, plus two synthetic namespaces: _spam.score for the spam score the filters produced (0-1), and _meta.country for the country the submission came from. Comparisons are case-insensitive, and numeric operators coerce the value, so budget is greater than 5000 works whether the field arrives as a number or a string.

• eq (is)
• neq (is not)
• contains
• not_contains
• starts_with
• ends_with
• gt (greater than)
• gte (at least)
• lt (less than)
• lte (at most)
• exists (is filled in)
• not_exists (is empty)
• in (is one of)
• regex (matches pattern)

Pattern matching (regex) accepts a regular expression, though patterns that nest one repetition inside another (like (a+)+) are refused, because they can take effectively forever to evaluate on shared infrastructure.

Full CRUD is available through the write API with the routes:write scope. A condition tree looks like this:

curl -X POST https://api.webforms.to/v1/forms/frm_xxx/routes \
  -H "Authorization: Bearer wf_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "High-value leads",
    "conditions": {
      "logic": "and",
      "conditions": [
        { "field": "budget", "op": "gte", "value": 5000 },
        { "field": "email", "op": "not_contains", "value": "spamdomain.com" }
      ]
    },
    "integrationIds": ["int_sales_slack"],
    "stopOnMatch": true
  }'

List with GET /v1/forms/:formId/routes, update a rule with PATCH .../routes/:id, reorder its evaluation position with POST .../routes/:id/reorder ({ "direction": "up" | "down" }), and delete with DELETE .../routes/:id. The default rule (the one with conditions: null) rejects any attempt to delete it, disable it, or give it conditions - the same guard the dashboard enforces, from the same validation function.