Tediware
Sign In
All updates

contentType added to API results + other API changes

Adrian Duyzer

Adrian Duyzer

feature

When you fetch a processing result from the platform Results API, each step lists the files it produced as artifacts. Until now, those artifacts told you only whether a file was the input or the output of the step - not what kind of file it was. Every artifact now includes a contentType, the file’s MIME type, so you can select a file by what it is rather than inferring its format from the processing direction.

How it works

Each artifact in a result’s detail.artifacts now carries a contentType alongside its id and usage:

"artifacts": [
  { "id": "1dc6a6fb-...", "usage": "input",  "contentType": "application/json" },
  { "id": "b613c64c-...", "usage": "output", "contentType": "application/edi-x12" }
]

There are two content types you’ll see:

  • application/json for the parsed or source JSON
  • application/edi-x12 for the EDI document

If you just want the product of a step, usage: "output" still works exactly as before - it gives you the parsed JSON on inbound and the generated EDI on outbound, and you never have to think about direction.

Where contentType helps is when you want a specific format regardless of direction. The JSON is the output on inbound but the input on outbound, so previously, pulling the canonical JSON across both flows - for indexing, analytics, or replay - meant mapping direction to input/output yourself. Now you can fetch it directly by content type. It also makes downloads cleaner, since you have the correct MIME type for setting response headers and file extensions.

This change is additive and backward compatible. Results created before content types were recorded simply omit the field, so existing integrations keep working unchanged.

Changelog

  • Added contentType to every artifact in the Results API, exposing each file’s MIME type so consumers can select a file by its format rather than inferring it from the processing direction.
  • Normalized the EDI content type to application/edi-x12 in both directions. Previously, generated outbound EDI was tagged differently from inbound EDI, which also gave it the wrong file extension on download. Both are now consistent.
  • Corrected the JSON content type to the standard application/json.
  • Improved artifact filenames. Downloaded artifacts are now named to match what was actually sent or received - the outbound EDI uses your delivery filename, and the corresponding JSON uses the same name with a .json extension - instead of an opaque identifier.
  • Backward compatible. Older results without recorded content types continue to work and simply omit the new field.