Documentation / QueryTek Tapestry glossary / Partner Adapter
A partner adapter translates between a platform's internal contract and one external system's interface. The platform holds a single normalized model of a request or record; the adapter absorbs the partner's specific formats, vocabulary, and failure behaviour so that variation never reaches the core.
Every external system has its own idea of a correct request: field names, identifier formats, pagination, what an error means. Absorbing those differences directly into core logic produces a system whose behaviour is a union of every partner's quirks, and where a single partner's change forces a change everywhere.
An adapter is the containment boundary for that variation.
One partner, one adapter. Each integration's peculiarities are isolated in a component that owns exactly that relationship, so partner-specific handling has an obvious location rather than being distributed through shared code.
A stable internal contract. The platform sends and receives one normalized shape. Adding a partner means writing an adapter, not amending the contract every other partner already depends on.
Explicit failure translation. Partners fail in incompatible ways — silent truncation, ambiguous status codes, partial success. The adapter maps those into failure states the platform understands, so a partner outage is a handled condition rather than an unexplained inconsistency.
The distinction from a client library is ownership of meaning. A client library speaks a protocol; an adapter maps semantics — deciding that the partner's "pending" corresponds to a particular platform state, and what to do when the mapping is not clean. That mapping is a decision with consequences, not plumbing.
The failure mode to watch for is leakage: partner concepts appearing in core models because one integration made it convenient. Once that happens the boundary is gone, and the next partner's differences have nowhere to be contained.
Adapters determine whether integration cost stays linear. Without them, each partner adds conditional logic to shared paths and the tenth integration is far more expensive than the first, because it must also avoid breaking the previous nine.
They also localize blast radius. When a partner changes an interface without notice, a well-bounded adapter fails in one place with a clear cause instead of producing inconsistent behaviour across unrelated workflows.
QueryTek Tapestry keeps partner-specific behaviour inside adapters so the routing and identity layers work against one normalized contract, which is what allows onboarding a partner to be a registration rather than an integration project. Adapter implementations, partner contract mappings, and credential handling are established during onboarding and are not published.
