Case Attachments and the Direct-Push Model

1The Model in One Paragraph

When a member forwards a file, the platform looks up the other party's registered storage endpoint and delivers the bytes straight to it. TSANet Connect does not keep a copy. There is no attachment store to read from later, and no server-side endpoint that lists the files on a case — if your integration needs a history, it keeps its own.

The design guidance around this model — the sending paths, the receiver patterns, and the operational decisions a receiving member has to make — is the subject of the companion topic page, Moving files between members. This document stays at the specification level.

2The Four Endpoints

All four are scoped to a collaboration request by token: this is the per-case layer. The baseline receiving configuration is registered per member with TSANet at onboarding (see the constraint in 2.1 and the companion topic); a token-scoped registration overrides it for that one case.

2.1 What a Receive Configuration Declares

The normalized HTTPS configuration requires domain, httpsPort, httpsPath, password and an expiration. In other words: where to deliver, on what port and path, with what credential, valid until when. Anything you register has to be an endpoint you actually operate and can receive on.

3Delivery Reaches Both Parties

A forward is not one delivery, it is two. The result object reports a receiverStatus and a submitterStatus, along with completeSuccess when both landed and partialSuccess when exactly one did. The sending member gets a copy of what they sent, delivered to their own registered endpoint. Each destination gets one delivery attempt with no automatic retry (source-read).

3.1 Per-File Statuses

Each file in a forward carries its own status on each side, drawn from a fixed set:

Treat partialSuccess as a first-class outcome in your UI rather than folding it into success or failure. An engineer who sees "sent" when only one side received the file will find out later, in the worst way. Because the status code is always 200, this is also the only way a total failure becomes visible.

4What the Platform Does Not Do for You

Two responsibilities sit with the connector, and both are easy to assume are handled.

4.1 No Case Note Is Created

Forwarding a file does not add anything to the case timeline. If an engineer on the other side should know a file arrived, your connector has to post the note saying so. The description you send with the forward is not what surfaces it.

4.2 No Attachment History Is Kept

There is no endpoint that lists the files previously forwarded on a case, because there is nothing server-side holding them. Any "attachments on this case" view is something your integration maintains from its own record of what it sent and received.

5Current State and Planning Guidance

Attachment receive capability is being rolled out per member rather than switched on platform-wide, and members are at different stages. Common storage arrangements — object storage in the member's own cloud account being the usual shape — are converging, so a member coming to this now should ask TSANet what the current recommended arrangement is rather than designing one from scratch.

Practical guidance while that continues:

• Do not assume a partner can receive. Check the configuration on the case before offering an attachment action, and handle CONFIG_MISSING as a normal outcome rather than an error.
• The link-in-a-note workaround remains valid where a partner is not yet enabled: upload to your own store and post the link as a case note. It is what most collaborations still use.
• Build the note yourself from day one (section 4.1), because that requirement does not change when enablement lands.
• Surface partialSuccess honestly. It will be the common case early on, while one side of a given pairing is enabled and the other is not.

5.1 In Development: Direct-to-Storage Delivery (Alpha)

The specification describes a second model, Attachment V2, with every operation marked x-stability-level: alpha. Beta served it first. Since 2026-10-26 Production serves the same specification, alpha markers included, though V2 has been exercised on Beta only. Instead of relaying the bytes, the platform issues the sender a short-lived grant to upload straight into the receiver's own storage (S3, Azure Blob or Google Cloud Storage per the specification) and confirms completion. The file still never comes to rest at TSANet, so the model in section 1 holds. Two things change that are worth knowing now:

• A receiver that has registered V2 storage can refuse the v1 forward with 409 attachment-direct-path-required. Both environments' specifications document it, so a sender should handle it wherever it forwards.
• The grants on a case can be listed. That is the first server-side record of attachment activity, though it is not a store of the files.

Section 4.1 is unaffected: a completed V2 grant does not post a case note or emit a webhook today, so your connector still writes the note. Do not build production flows on V2 until it leaves alpha. The Java client's V2 support is described on Connect SDK.

6Revision History