Moving files between members — TSANet Connect Developer Hub

The reframe

A conduit, not a drive

It is tempting to picture case attachments as uploads to a shared workspace: the file goes up, and the partner comes to get it. The platform does the opposite. Attaching a file to a collaboration case triggers a delivery — TSANet takes the file and pushes it into the file store the receiving member registered, using that member's own transfer method and credentials. Partner engineers find the file where they already work, not on a second website.

The API is honest about this: there is a call to attach files to a case and calls to manage receiving configuration, and no download endpoint at all. A file, once attached, has exactly one direction of travel — outward, into the parties' stores.

Delivery fans out to the registered stores of both parties on the case — the sender's own store receives a copy of what it sends. Useful for audit, surprising if you did not plan for it.

Attaching a file does this	Which means
Delivers into the receiver's registered store	The partner's engineers get the file in their own tooling. There is no portal step and no second login.
Reports the delivery outcome to the caller	The sender learns whether each destination succeeded. Nobody else is told automatically.
Creates no case note by itself	Announcing the file on the case is the connector's job — see sharp edges.

The sending side

One call, three ways to make it

Sending is a single API call on the collaboration case: attach one or more files (multipart, with a required description of up to 500 characters in the form body — the GitBook reference shows it as a query parameter; see the API page) to the case token you already hold. The platform resolves the receiving side's configuration and does the rest. The official reference is the case attachments documentation.

Your connector does it. On platforms with a shipped connector, attachment support arrives as connector functionality — no member code involved.
The Connect SDK. The Java SDK carries attachment forwarding as a library call, for members building their own integration — and the Connect Gateway sends through the same library, so gateway-class connectors inherit attachment sending rather than reimplementing it.
Direct REST. The endpoint is the contract; any stack that can make an authenticated multipart request can send. Nothing requires the SDK.

Delivery is per destination: with two configured stores on a case, each gets its own attempt and the response distinguishes complete from partial success. There is one attempt per destination — no automatic retries (documented behaviour, not probed on this hub) — so a failure is loud for the caller and invisible to everyone else until someone acts on it.

The receiving side

Register how you receive

Each member registers a receiving configuration with TSANet — per company, set up during onboarding, with per-case overrides possible. The baseline method, live in production today, is the normalized HTTPS push: five fields of configuration, and one request shape your endpoint must answer.

{
  "domain":    "files.example-member.com",
  "httpsPort": 443,
  "httpsPath": "/tsanet/uploads",
  "password":  "<pre-shared secret>",
  "expiration": "2027-01-01T00:00:00Z"
}

With that registered, every case file arrives at your endpoint as:

PUT https://files.example-member.com:443/tsanet/uploads/<fileName>
Authorization: Basic base64(<caseNumber>:<password>)   ← case correlation rides here
Content-Type: <the file's own media type>

<raw file bytes>                                      ← not multipart

Anything that answers this request qualifies as a receiver — it is an afternoon of work in any stack, and a small ingest service in front of object storage (S3, Azure Files, or similar) is the common pattern. Any 2xx you return counts as delivered, which is a sharper contract than it looks: see sharp edges.

When your store cannot answer a PUT. Members with an established file repository that has its own upload protocol do not have to bolt an endpoint onto it — TSANet can implement a member-specific delivery method against the repository's existing interface, configured platform-side. The normalized method is the default; member-specific methods are how established repositories join without changing. They are arranged with TSANet rather than exposed on the API — the published surface registers only the normalized HTTPS configuration. If yours is in that camp, start the conversation with what your store's upload interface looks like.

Designing yours

The five decisions every receiving member makes

Whichever method you land on, the same five questions decide whether file exchange works quietly for years or generates a support thread a month. They are worth answering in writing before the first test file moves.

Decision	The question	Why it bites
Authentication & rotation	What credential does TSANet hold to reach your store, who rotates it, and how is rotation communicated ahead of time?	The configuration declares an expiration. A credential that silently dies makes its first appearance as a failed delivery on a live case.
Case correlation	Which case identifier links an arriving file to the right case, and where does it travel — auth username, upload parameter, filename, path?	On the normalized method the case number is the Basic-auth username and nothing else identifies the case. If your ingest drops it, you own a pile of orphaned files.
Filenames & collisions	What characters do you accept, and what happens when the same name arrives twice — overwrite, version, or reject?	Receivers differ on this today, and silent overwrite is a common object-storage default. Whatever you choose, engineers on both sides should not have to guess.
Size & limits	What is your maximum file size and write timeout?	Support archives are large. A limit nobody wrote down becomes a mid-transfer failure on the day it matters.
Arrival notification	Does your system tell the case owner a file landed, or is the case note the only announcement?	The platform does not create the note. If neither your store nor your connector announces arrivals, files land in silence.

Sharp edges

What goes wrong, in the order you will meet it

2xx is a promise. One attempt, no retries — so return success only after the file is durably committed. A receiver that answers 200 from a buffer and fails afterwards has converted a recoverable error into silent loss, and nobody upstream will retry on your behalf.
The note is not automatic. The platform delivers the file and stops; announcing it on the case is the sending connector's job. If you build a sender, create the note. If you build a receiver, do not treat the note as the signal that a file exists — it may arrive before, after, or not at all.
Same-name uploads. The live receivers do not agree on collision behavior, and some ignore duplicates silently. Pick a policy, implement it, and write it down where partners can see it.
Filenames travel in URLs. On the normalized method the filename becomes a path segment. Conservative ASCII names survive everywhere; spaces and non-ASCII characters are where interoperability goes to die.
Your own store gets a copy. Delivery fans out to both parties' configurations. That is useful for audit and surprising for capacity planning — size your store for what you send as well as what you receive.
Expiry is declared, not managed for you. The config's expiration is a statement about your credential, and rotation is an operational duty on your side. Put it on a calendar, not in a memory.

Questions about a store or method not covered here — or a repository with an upload interface you think should be supported — belong in Community. The case attachments reference is the authoritative contract, and design doc TSANET-2026-002 specifies the direct-push model, the config endpoints and the per-file delivery statuses in full; this page is the design guidance around both.