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.

Working with the API Compare the connectors
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 →

Connectors & Gateways

Production integrations maintained in the tsanetgit organization. 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, 15-minute scheduled sync, auto-approval flows by asset serial.

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: TSANet hosts and operates the adapter, because Intercom runs no member code in-workspace. Canvas Kit panel in the Help Desk.

Architecture & platform notes → Work in progress · v2.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 → v2.0.0 · Java

TSANet Connect SDK

A Java client generated from the Connect API spec, wrapped in nine 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 →

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 all 27 paths live in the GitBook reference, generated from the spec. Not duplicated here — but one known drift from the spec is flagged.

 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. 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.

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

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

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