Batch & Jobs

Async conversion in one call

For volumes beyond the synchronous 2 MiB / one-message-at-a-time model, enqueue a batch (up to 16 MiB per request):

curl -sS -X POST https://api.transmute.403fin.io/v1/convert/batch \
  -H "Authorization: Bearer $TRANSMUTE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "camt.053",
    "items": [
      {"message": "{1:F01AAAADEFF...}"},
      {"message": "{1:F01AAAADEFF...}"}
    ]
  }'
# 202 → {"id": "6f1e...-uuid", "status": "queued", ...}

Requires the convert scope. If the deployment has no job encryption configured, batch routes answer batch-unavailable 503 — the synchronous API is unaffected.

Poll the job

curl -sS https://api.transmute.403fin.io/v1/jobs/$JOB_ID \
  -H "Authorization: Bearer $TRANSMUTE_KEY"
# {"id":"...","status":"completed","items":[{"status":"ok","result":"<?xml ...","warnings":[...]}, ...]}

• GET /v1/jobs/{id} needs the jobs:read scope (granted by default).
• DELETE /v1/jobs/{id} purges a job and its results early.
• Job ids are tenant-scoped: another tenant's job id is a plain not-found 404, indistinguishable from a nonexistent one.

Prefer push over polling? Register a webhook and receive a signed job.completed event.

How batch storage works (the privacy story)

Batch is the one place transmute holds message data at rest, and it's engineered to minimize that:

• Item inputs and results are stored AES-256-GCM encrypted.
• Inputs are purged the moment an item completes — only results remain.
• Results live under a short TTL (default 1 hour, max 24) and are then swept; DELETE purges earlier.
• Webhook bodies carry metadata only — never message content.

Billing

Each item that the engine processes bills like a synchronous conversion (same 2xx/400/422 rules); queued-but-never-processed items don't.