Validate & publish

Your draft config — merchant + receiving + catalog + the newest policy version — only goes live when you publish it. Publishing runs the same validator the CLI's config validate uses, then flips the newest policy version active in one transaction and invalidates the manifest cache.

POST /v1/validate

Run the SDK's pure validateConfig() over the draft config assembled from current DB rows. No side effects — a dry run that returns reason-coded findings.

{ "ok": true, "findings": [] }

{
  "ok": false,
  "findings": [
    { "code": "RECEIVING_NO_RAIL_ENABLED", "human": "Configure at least one rail." }
  ]
}

ok is true only when findings is empty. The endpoint always returns 200 — the findings are the payload, not an HTTP error.

curl -X POST "https://api.veto-ai.com/v1/validate?merchant_id=mrch_01J…" \
  -H "Authorization: Bearer veto_test_8f2c…"

POST /v1/publish

The publish gate. (1) Validates the draft; if invalid, refuses with 422. (2) In one transaction, deactivates the current active policy and activates the newest version. (3) Invalidates the manifest cache so the next discovery serve rebuilds from the published inputs.

Response — 200

{ "published": true, "ok": true, "active_policy_version": 4 }

Response — 422 (validation failed)

{
  "published": false,
  "ok": false,
  "findings": [ /* … */ ],
  "reason_codes": ["CONFIG_INVALID"],
  "error_human": "Config did not pass validation; fix findings before publishing."
}

Status codes

curl -X POST "https://api.veto-ai.com/v1/publish?merchant_id=mrch_01J…" \
  -H "Authorization: Bearer veto_test_8f2c…"