How Poly fits together¶

Poly is an API integration platform. You put catalog resources in a Tenant → Environment, authenticate with an API key, and call them through a generated SDK (poly.<context>.<name>) or REST.

Five pieces¶

Tenancy. A tenant owns users and environments. Keys are bound to one environment. Authentication model
Catalog + context. Resources named (context, name) become poly.a.b.name. Context
Function kinds. API Function = gateway outbound HTTP. Server Function = hosted FaaS. Client Function = in-process helper. Functions
Ingress and jobs. An API Endpoint (webhook handle) is inbound HTTP. Triggers and Jobs call server functions with three Event args (not CloudEvents). Events and Triggers
Surfaces. PolyUI to manage. CLI/SDK to build and call. Swagger to automate. Canopy is the UI shell, not the whole platform.

Request flow (SDK)¶

poly.myContext.fn(args)
  → HTTP POST /functions/{api|server}/:id/execute  (Bearer key)
  → Auth resolves tenant, environment, permissions
  → API Function: gateway applies the trained template → third party
  → Server Function: Knative invoke → response
  → Client Function: no remote execute; runs in the caller

Inbound HTTP hits a webhook handle, optional security functions, then Triggers. GraphQL subscriptions use [event, params] instead of the three Event names.

Where to go next¶

Choosing a Poly resource

Platform architecture