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.

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.

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.

6Revision history