Formats
GET /v1/formats — the live registry of supported message formats, versions, and conversion pairs. Always trust this endpoint over any static list.
The live registry
GET /v1/formats returns every format this deployment supports, with the conversions each can make:
curl -sS https://api.transmute.403fin.io/v1/formats \
-H "Authorization: Bearer $TRANSMUTE_KEY"
[
{
"id": "mt940",
"name": "MT940 Customer Statement",
"kind": "mt",
"versions": [],
"convertsTo": ["camt.053", "normalized-json", "csv", "ofx", "..."]
},
{
"id": "camt.053",
"name": "Bank-to-Customer Statement",
"kind": "mx",
"versions": ["camt.053.001.02", "camt.053.001.08", "..."],
"convertsTo": ["mt940", "normalized-json", "..."]
}
]
| Field | Meaning |
|---|---|
id | The value you pass as from/to on convert/normalize/validate |
kind | mt (SWIFT MT), mx (ISO 20022), file (render-only targets like CSV/OFX for accounting imports), json (the normalized-json pseudo-format) |
versions | Supported message versions; pin one with targetVersion |
convertsTo | Valid to values from this source |
Use it, don't hardcode it
The registry grows with Standards Releases and new format support. Query it at startup (or cache it briefly) rather than baking a pair list into your code — asking for a pair outside the registry gets an unsupported-conversion 422, and the supported list in the error detail comes from this same registry.
kind: "file" targets are render-only: you can convert to CSV/OFX/QBO for accounting-system import, but those files can't be a from.
The endpoint requires the formats:read scope (granted by default) and is never metered.