A file attached to a collaboration case is delivered into the receiving member's own file store — not parked on a portal for someone to fetch. The sender never learns how the receiver stores files, and that one-way ignorance is what makes the system extensible: each member registers how they receive, once, and every partner can send to them without changing anything.
The reframe
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.
| 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, in the response body. The HTTP status is 200 whatever happened, so read completeSuccess and the per-side statuses. 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
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) 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.
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 (source-read, not probed on this hub) — so a failure is loud for the caller and invisible to everyone else until someone acts on it. "Loud" means the response body: the call answers 200 either way, so a caller that checks only the status code hears nothing.
409 attachment-direct-path-required. The Connect SDK already carries a V2 client, and TSANET-2026-002 §5.1 has the specification-level summary. Don't build production flows on it yet.The receiving side
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 multipartAnything 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.
Designing yours
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