Attachments & Binary Responses AI-generated

Files can be uploaded to an environment once (Environment → Attachments) and then referenced by name from any reaction's Response Attachments field - as a plain binary download, or as a SOAP attachment.

Managing attachments at the environment level

Use Add Attachments to upload one or more files at once. Each attachment's name is its unique identifier - it's what reactions reference, so renaming one means updating every reaction script that names it. Clicking an attachment's name opens an editor for its metadata (filename, Content-Type header); deleting an attachment there is permanent (short of re-uploading it). Cloning an environment carries its attachments along with everything else.

Referencing attachments from a reaction

The Attachments field accepts several forms, in both JSON and XML syntax:

• A single name: "Contract.pdf" - Content-Type and a default Content-ID (Content-ID-1) come from the attachment's own stored metadata.
• A list of names: ["cat.png","mouse.png","hedgehog.png"] (JSON) or ("cat.png","mouse.png","hedgehog.png") (XML).
• A list with explicit per-attachment overrides - JSON: {"name":"file.xlsx","content-type":"application/vnd.ms-excel","content-id":"CONTENTID200"}; XML: <attachment><name>file.xlsx</name><content-type>application/vnd.ms-excel</content-type><content-id>CONTENTID200</content-id></attachment>.

Attachment selection can be scripted, not just static - e.g. building the JSON array (or XML sequence) dynamically from account properties or request conditions, to attach different files depending on which account or request matched. Content-Transfer-Encoding is always binary and isn't configurable. Non-English attachment names are RFC 2231-encoded (some legacy clients don't support this).

SOAP attachment styles

For SOAP responses, the Style toggle picks the wire format: MIME/SWA (the default - standard multipart/related, with type="text/xml" for SOAP or type="application/json" for JSON) or MTOM/XOP (the modern binary-optimized packaging most current SOAP stacks expect, using type="application/xop+xml" - the payload must contain an <xop:Include/> element referencing the attachment's Content-ID, or clients may ignore the attachment entirely). The legacy SWAREF referencing style is also supported for clients that specifically need it.

Plain binary downloads

A reaction doesn't need to be SOAP to return a binary payload - referencing an attachment with an appropriate content-type on an otherwise ordinary REST reaction is enough to mock a plain file-download endpoint.