Validate
POST /v1/validate — syntax and schema validation with structured findings. Message problems come back as findings in a 200, not as errors.
The contract
POST /v1/validate checks a message and always answers 200 for content-level problems — an invalid message is a successful validation with findings, not an API error:
curl -sS -X POST "https://api.transmute.403fin.io/v1/validate?from=mt940&level=schema" \
-H "Authorization: Bearer $TRANSMUTE_KEY" \
-H "Content-Type: text/plain" \
--data-binary @statement.mt940
{ "valid": false,
"findings": [
{ "severity": "error", "path": ":62F:", "detail": "closing balance missing" }
] }
You only see 4xx errors for API-level problems: unparseable request forms (invalid-input), unknown formats (unsupported-format), and the like.
Validation levels
level | Checks |
|---|---|
syntax | Tokenization, field grammar, envelope structure |
schema | Everything in syntax, plus XSD validation for MX / field-content rules for MT |
cbpr | CBPR+ usage-guideline checks — license-gated; without the entitlement it is rejected like any unknown level (400) |
Reserved level names (e.g. network) are rejected with a 400 — if you need network-rule validation, tell us; it's on the roadmap.
Request forms
Identical to Convert: JSON envelope or raw MT/XML body, from auto-detected when omitted.
Billing note
Validation is a metered route: a 200 — valid or not — is billable work on a live key, as is a 400/422 (the engine parsed your input to reject it). Test keys never bill. See Test vs Live Keys.