What is transmute?

Overview

transmute is an API-first conversion service for financial messages:

• Convert — SWIFT MT ↔ ISO 20022 (MX) in both directions, e.g. MT940 → camt.053 or pacs.008 → MT103, plus file render targets for accounting imports.
• Normalize — either family into one canonical JSON shape, so your application parses a single format regardless of what your counterparties send.
• Validate — syntax and schema validation with structured findings.
• Enrich — BIC and structural reference checks.

Everything is driven by three endpoints (POST /v1/convert, POST /v1/normalize, POST /v1/validate) behind a bearer API key. The interactive endpoint reference generated from our OpenAPI document is always available at api.transmute.403fin.io/docs.

"SWIFT" is a trademark of S.W.I.F.T. SCRL. transmute converts SWIFT MT messages; it is not affiliated with, endorsed by, or certified by SWIFT.

Privacy: stateless by design

Your message contents are never logged, and only metadata (message type, byte size, duration, status code, warning codes) is recorded, for metering and billing. That applies to every surface: database, logs, metrics and traces.

Bodies live in request memory. Two things hold data for a limited time, both documented:

• The idempotency replay cache. If you send an Idempotency-Key header on any POST, the full response (for a conversion, the converted message, up to 1 MiB) and a SHA-256 of your request body are kept for 24 hours, so a retry gets the same answer. Without the header, nothing is cached.
• Batch jobs. Batch items are stored as AES-256-GCM-encrypted rows in Postgres, never as files. Each input is deleted when its item completes. Results are deleted when the job's TTL (default 1 hour, at most 24 hours) runs out, counted from when the job completes. DELETE /v1/jobs/{id} removes a job at any time.

A synchronous request sent without an Idempotency-Key leaves nothing behind except its metadata usage record.

Nothing is lost silently

Conversion between formats with different capacities is inherently lossy at the edges — a long remittance string may not fit an MT field; MT940 has no creation timestamp that camt.053 requires. transmute's contract is that every lossy or assumed step surfaces as a structured entry in the warnings[] array, with a stable code from a closed warning registry. If the response carries no lossy warnings, nothing was dropped.

How requests work

POST /v1/convert          Authorization: Bearer tk_live_...
  body: raw MT text, raw ISO 20022 XML, or a JSON envelope
  →   { "result": "...", "warnings": [...], "meta": {...} }

Errors are always RFC 9457 application/problem+json with a type URI that resolves to a page in the error catalog. Money amounts in canonical JSON are strings, never floats.

Next steps

1. Create an account in the portal.
2. Get an API key — start with a tk_test_ key: never billed, with a one-time 250-request allowance to evaluate everything.
3. Run the quickstart: convert an MT940 in one curl.