Everything you use while building against TSANet Connect, in one place: the environments and the test flag, the reference and the Postman collection, the SDK and its demo, the test suites, and the agent skills. Each entry says what it is for, how you get it, and what access it needs. Things that exist but are not reachable by members yet are marked, with what to do instead.
Environments
Build and test on connect2.tsanet.net; production is connect2.tsanet.org. Beta and production behave differently often enough that "which environment" is the first question anyone will ask about a problem. Every call is scoped to your member identity, so GET /v1/me is the cheapest check that your credentials resolve to the company you expect.
Get it a Beta account and credentials from membership@tsanet.org; for OAuth client credentials, TSANet also has to provision your service principal before an app-only token is accepted.
The authentication rules →Create cases with testSubmission: true while you build. It suppresses SLA timers and partner notifications, so nothing you send reaches a real partner's queue. You write testSubmission and read back testCase; that read-back is how you confirm a go-live flip actually happened. Every case that is not test-flagged reaches a real partner.
Get it nothing to install — it is a field on the create request.
Collaboration requests →Reference & Postman
Request and response schemas, parameters and status codes generated from the specification. It covers the original 27 paths and GET /v1/note-types; the alpha Attachment V2 paths both environments now serve are not in it (checked 2026-10-28). It has run ahead of the platform in places — the v2 webhook options it showed before Production's specification carried them (it has since 2026-10-26), and a secret-rotation call that Beta answers with 501 — and the API page flags where. The behaviours the reference does not tell you about — the default HTTP 500 error mode, the two note fields, the webhook version trap — are what Working with the API is for.
Get it in GitBook, alongside the integration guide and the models.
API Reference →Every endpoint as a request you can send against Beta with your own credentials. Send Accept: application/json, application/problem+json on every request, or rejections come back as HTTP 500 with no usable detail.
Get it in GitBook. The OpenAPI file the reference and the SDK are generated from is not published; ask membership@tsanet.org for it if you are building a code generator or an agent's tool definitions around it.
Postman collection →SDK & Demo
The Java client, generated from the specification and wrapped in ten typed facades. Published to GitHub Packages as a public package; only the current release, v3.0.0, is supported. 3.0.0 is a breaking major — read its upgrade note before moving from 2.0.0. A token with read:packages is still required to resolve it, even for public artifacts.
Get it as a Maven dependency from GitHub Packages; the coordinates and the token requirement are on the SDK page.
Connect SDK → Getting it →A command per operation — create, approve, reject, information request and response, notes, close, attachments, webhooks — and an optional endpoint that receives webhooks into a local store. The source is public, but the build reads the specification from a private repository, so a clone alone does not build.
Get it a built jar from TSANet at onboarding, or spec access if you need to build it yourself.
A branded web demo over the SDK facades: dashboard, partner search, the partner's form rendered live, every lifecycle action, webhook management. It is not published as an artifact and there is no hosted instance members can sign into yet. How members get it — a TSANet-hosted instance or a hand-over — is being decided.
Until then ask membership@tsanet.org for a jar or image; if you host it, set TSANET_DEMO_AUTH_PASSWORD or it runs with no auth gate. Runbook on the SDK page.
Test suites
For anyone writing an adapter on the Connect Gateway: it drives your real adapter through Connect's failure modes — timeouts, ambiguous submits, duplicate inbound deliveries — and certifies the seam between your code and the engine. Run it continuously from day one, not once at the end.
Get it the conformance module publishes with the gateway at v3.0.0 from the repository's package registry; the repository is private and access comes with adapter onboarding. Details under Building an adapter.
TSANet's own local harness for testing connectors end to end against the Connect API: contract, webhook (v1 and v2 CloudEvents) and SDK-conformance suites, connector unit suites, and end-to-end drivers for the shipped CRM connectors. It is internal today. Whether members should see it, and in what form, has not been decided.
Until then the Beta environment with test-flagged submissions is the member-facing test bed, and the connector issue trackers are where a failing case goes.
Connector issue trackers →Agent skills
Each shipped skill was distilled from the production implementation it sits next to, and loads into any assistant that reads the open skill format. What each carries, and how to load one, is on Agentic Usage with TSANet Connect.
| Skill | For | Access | Where |
|---|---|---|---|
| Zendesk connector | Building or extending the ZAF + ZIS connector | Public | Zendesk → Build with an assistant |
| Connect SDK deployment | Consuming the artifact, credentials, the demo runbook, troubleshooting | Public | SDK → Build with an assistant |
| Fin / Intercom deployment | Deploying the hosted adapter for a member workspace | Access at onboarding | Fin / Intercom → Build with an assistant |
| Gateway adapter author | Writing your own adapter against the contract | Access at onboarding | Gateway → The authoring kit |
| The hub assistant | Asking this site questions from any page | Not yet public | The launcher is in this site; the agent behind it is not created yet — what it will be |
Where to go next
Build on the Connect Gateway, use the SDK, build against the API directly, or tell us the platform. One question decides between them: will your platform run your code inside the member's tenant?
Build a New Integration → Worked exampleThe ServiceNow assessment is what scoping looks like before code exists: every claim tagged documented or needs-probe, and the open questions listed with what each one blocks.
Platform assessment → QuestionsConnector bugs go to that connector's tracker, credentials and pilots to membership, everything else to the organisation's discussions.
Community →