The Technology Support Alliance Network · 900+ member companies

Connect to One.
Build for Anyone.

The engineering home for TSANet Connect: connectors, gateways, the REST API, and the design documents behind the platform. Built and maintained by TSANet, for the members who automate multi-vendor support.

Build a new integration Working with the API
TSANet Developer Hub
Collaboration case lifecycle token: TSN-88F2-C1A7
OPEN
You submit · clock running
INFORMATION
Partner asks · optional
ACCEPTED
Partner takes it on
CLOSED
Only you can close
POST /v1/collaboration-requests — you submit; the response clock starts

One path through an outbound case. INFORMATION is optional, REJECTED is the other terminal state, and the response clock stops at the partner's first reply whichever it is — not at closure. The lifecycle rules →

Build a New Integration

Your platform has no connector, or you are wiring Connect into something of your own. One question about the platform decides which of four routes fits; they are ordered by how much you have to build.

Start here →
Work in progress · v3.0.0

Build on the Connect Gateway

TSANet supplies the engine, the contract and a conformance harness; you write only the half that talks to your platform. The route when the platform will not run your code in the member's tenant.

Design & adapter guide → v3.0.0 · Java

Use the SDK

A Java client with typed facades, validation and both auth modes, as a public package. The shortest JVM path that is not hand-rolled HTTP.

Library reference → Pattern

Build Against the API

Your platform's events in, Connect API calls out, updatedAfter polling back. For any stack; read the behaviour guide before you design.

Working with the API → Wish list

Tell Us the Platform

Which platform your team runs on decides which connector gets built next. If yours is common, waiting may be the right route.

Community →

Whichever route: settle first whether the platform runs your code inside the member's tenant, then build on Beta with test-flagged submissions. The first week is the same on every route, and the tools are collected in one place.

Build Against the API

The behaviours that cost integrators time, gathered from building four connectors and a Java client against it. The endpoint reference lives in GitBook and is generated from the spec — this is the layer underneath it.

Working with the API →
Reference

The Endpoint Reference

Schemas, parameters and status codes for every path outside the alpha Attachment V2 set live in the GitBook reference, generated from the spec. Not duplicated here — where GitBook and the spec disagree, the hub says so.

 Errors

Two Response Modes

By default most rejections return HTTP 500 — indistinguishable from an outage. One Accept header gets you documented status codes and RFC 7807 bodies.

 Auth

Login & Identity

OAuth 2.0 client credentials is the current server-to-server path; POST /v1/login is legacy. Members now issue their own client secrets in the webapp. Watch the scope format — the obvious one fails.

 Partners

Discovery & Forms

Fetch the process form fresh every time, and parse its SELECT options on newlines rather than commas.

 Cases

Collaboration Requests

Save the token immediately. There is no idempotency key on create, and responded — not the status name — is what gates the SLA.

 Content

Notes & Attachments

Two note fields rendered as two sections, so never copy one into the other. Attachments need both sides configured.

 Webhooks

Event Delivery

v1 and v2 both accept your subscription and deliver different type strings. Payloads are thin; delivery is at-least-once, so build for duplicates.

 Sunset

Deprecation Clocks

Three v1 paths sunset on 2027-01-01: the case list and both webhook paths. Everything else has no v2 and no clock, so the migration is smaller than it sounds.

Existing Solutions

The shipped integrations, maintained in the tsanetgit organization — and, if you are building your own, the worked examples of the routes above. One connection reaches every partner member.

Compare all connectors →
GA · managed package

Salesforce

LWC on the Case record page, TSANet Cases as a related list, Named Credential auth, 15-minute scheduled sync, an asset-match auto-accept template.

Architecture & setup → GA · Power Platform

Microsoft Dynamics

Managed solution in your own environment: Dataverse tables, a plugin assembly, Power Automate flows, and field mapping driven by a configuration table.

Architecture & setup → Not built · committed 2026

ServiceNow

Not built yet. A platform assessment of the surfaces, Table API traps and distribution choices an eBonding integration has to design around.

Platform assessment → GA · app

Zendesk

Two layers in your own tenant: a ZAF sidebar app for agents, and a ZIS integration for inbound push and public-reply forwarding.

Architecture & setup → Early access · gateway

Fin / Intercom

The first gateway-class connector: the adapter runs outside Intercom, because Intercom runs no member code in-workspace. TSANet-hosted or self-hosted in your own cloud. Canvas Kit panel in the Help Desk.

Architecture & platform notes → Work in progress · v3.0.0

Connect Gateway

One shared TSANet-facing engine, thin per-platform adapters: the machinery behind Fin / Intercom, and the contract a member or vendor builds their own adapter against. The least effort when your platform has no connector.

Design & adapter guide → v3.0.0 · Java

TSANet Connect SDK

A Java client generated from the Connect API spec, wrapped in ten typed facades — plus a console app, attachment receiver and web demo. Python and TypeScript not started.

Library reference → Pattern

Build Against the API

The translation-service pattern: your platform's events in, Connect API calls out, updatedAfter polling back. Read the behaviour guide before you design.

Working with the API →

Design Document Library

Interactive, web-native engineering documents. Published straight from the repo — every document is a page, not a PDF. The library is new; these are the first entries.

All design docs →
TSANET-2026-001Specification · Draft

The Canonical Case Model

One case, two schemas: where the write and read models diverge, how custom fields arrive from the form template, the two storage philosophies connectors have chosen, and the mappings that have no clean answer yet.
TSANET-2026-002Specification · Draft

Case Attachments and the Direct-Push Model

The platform brokers file transfer and never stores it. What that forces on the connector, why delivery reaches both parties, and the two responsibilities the platform leaves entirely to you.
CONNECTORArchitecture

Fin / Intercom: The Gateway Adapter Class

Why a hosted gateway rather than an installed app, the runtime as built, and the submit-outcome taxonomy that parks ambiguous submits for reconciliation rather than retrying them into duplicates.
CONNECTORArchitecture

Zendesk: Two Layers in Your Own Tenant

ZAF sandbox constraints, ZIS integration naming, the three-audience note visibility model, and the API-token retirement clock.
PLATFORMAssessment

ServiceNow: What the Platform Forces

A pre-implementation map with every claim tagged by evidence level — surfaces, Table API traps, and the distribution choice certification gates.

Topic Areas

Cross-cutting write-ups that are not tied to one connector or one endpoint.

All topics →

Two Ways to Build a Connector →

One question about your platform — will it run your code inside the member's tenant? — decides who operates the integration, where credentials live, whether connector faults are independent or correlated, and whether shipping a fix means asking every member to upgrade. The taxonomy behind every connector on this hub, plus a four-question procedure for a platform that is not on it yet.

Read the topic In-tenant · Salesforce, Dynamics Partial · Zendesk Gateway · Fin / Intercom Undecided · ServiceNow

Deciding What to Accept Automatically →

Three of the four shipped connectors can accept inbound cases without an agent, the fourth refuses to, and they disagree completely about when that is wise. Accepting stops the SLA clock and tells a partner an engineer is engaged — so a false acceptance is worse for them than an honest breach. Four shipping postures, and how to build a rule that asserts something actually true.

Read the topic Accept everything · Zendesk Match existing work · Dynamics Verify entitlement · Salesforce Human commits · Fin / Intercom

Moving Files Between Members →

A file attached to a collaboration case is delivered into the receiving member's own file store — not parked on a portal. The sender never learns how the receiver stores files, which is exactly what makes the system extensible. How sending works, what the normalized receiving contract requires, the five decisions every receiving member makes, and the sharp edges around one-attempt delivery.

Read the topic Live · normalized HTTPS push Sending · connector, SDK, or REST Pattern · endpoint fronting object storage Alpha · direct-to-storage delivery

Agentic Usage with TSANet Connect →

Working on Connect with an AI agent rather than by hand, whichever provider's agent it is. The four skills TSANet ships and how any assistant loads them, the assistant embedded in this hub and the recipe for the Copilot Studio agent behind it, what every provider's framework needs from the API and the auth gap that separates hosted builders from code-first ones, plus a documented-only assessment of Copilot Studio with Claude.

Read the topic Shipped · four agent skills Shipped · the hub assistant launcher Assessed · Copilot Studio Compared · Anthropic, Microsoft, OpenAI, Google

End-to-End Encryption of Case Content →

Case text that only the two members on the case can read, with the keys at each member's own connector and none on the platform. The two API fields that carry it, how the one proof-of-concept implementation encrypts and signs, where every connector stands, and the platform behaviour that currently breaks the signature.

Read the topic Live · two API fields PoC · Dynamics Not yet · SDK, Gateway Open · sanitizer rewrites ciphertext

On the List, Not Written Yet

Headings that appear elsewhere on the hub but have no topic page, because nothing has been assessed behind them and a page that summarises nothing would be worse than an empty slot. What each one is waiting on →

AI-native support platforms · Pylon, DevRev, Wolken, Agentforce, Zendesk AI, Now Assist Email-to-case patterns Swarming & case ownership SLA & escalation design

Orange-edged cards above have a published write-up. Fin / Intercom is the one AI-native platform that has been probed; it has a connector page rather than a topic.

Community

Discussion runs in the tsanetgit organisation Discussions, one space shared by every TSANet repository — no separate accounts, no separate platform. Pick the category that fits.

Where to take what →
Q&AAsk an implementation questionAuth, process forms, lifecycle transitions, webhook delivery TroubleshootingSomething isn't workingSilent failures, signature mismatches, sync that stopped Show and tellShare what you builtCustom integrations, translation services, platform findings Technology CommitteePropose a change to the APIGaps, papercuts, roadmap input, and behaviour that surprised you Wish ListWhich connector next?Tell us the platform your team actually runs on MembershipEarly access & onboardingCredentials, pilot instances, connector early-access programmes

A bug or feature request in a shipped connector goes to that connector's public issue tracker, where the maintainers and the history already are. Fin / Intercom, the Connect Gateway and ServiceNow have no public tracker yet; route those through membership.

Anything involving credentials or account changes still goes to membership@tsanet.org — a discussion thread is public, and credentials never should be.

The wish list is the one we most want answered. Which platform your team runs on is the single most useful thing you can tell us, and it is what decides which connector gets built next.

Browse the discussions Get in touch