Platform Overview

The PolyAPI Platform consists of:

  • A cloud-agnostic managed serverless platform built on Knative providing full observability into your integrations and services.

  • A central gateway for inbound API Endpoints (webhooks), outbound API Functions, and server function execute.

  • A unified catalogue of vendor and internal APIs, functions, and webhooks, accessible via a generated SDK or our RESTful API.

  • A helpful AI assistant embedded in your IDE to help you explore your catalogue and write integrations.

  • A web portal to see and manage all your resources, and to host your own custom CRUD applications with auto-generated UI.

There are currently 2 separate, managed instances of our serverless platform that you can sign up for:

PolyAPI can also be self-hosted, allowing you to deploy it anywhere Kubernetes is supported.

PolyAPI Resources

Which type to create: Choosing a Poly resource. How the instance is put together: Platform architecture.

Poly makes it easy to create, host, and manage all the resources needed for any cloud service:

  • Functions

    • Server Functions - Knative serverless functions that run in our cloud

    • Client Functions - Shared functions that run wherever they are executed

    • API Functions - API calls to third-party services invoked via our gateway

    • AI Functions - LLM calls with optional tool functions, invoked via our gateway

  • Variables - Variables and secrets which are stored securely and can be injected into your functions at runtime

  • Tabi Tables - Managed PostgreSQL tables for structured, high-volume row data (SDK tabi.<context>.<Table>)

  • API Endpoints (Webhooks) - Public HTTP ingress on the Poly gateway. Canopy still labels these Webhooks

  • GraphQL Subscriptions - Long-lived provider event streams that invoke Poly server functions when new events arrive

  • Triggers - Bind a webhook or error handler to a server function

  • Jobs - Execute functions at a set time, interval, or CRON schedule

  • Schemas - Shared JSONSchema definitions to type your events and application data

  • Snippets - Copy-paste snippets for config, markdown, or language-specific boilerplate

  • Permission Policies - Grant a permission set and environment membership (used by SSO)

  • Identity Providers - OIDC IdP registration for SSO

  • Context - Dot-separated namespace that becomes poly.<context>.<name>

  • Visibility - ENVIRONMENT / TENANT / PUBLIC discovery

All PolyAPI resources you create will be catalogued, documented, and made available to your team in a custom SDK generated in any supported language.

Tenants, Environments & Visibility

Within a Poly Instance there can be many Tenants. Tenants typically have 1-to-1 relations with a company that uses Poly (except in the case of self-hosting), and billing for services on PolyAPI are billed on a per-tenant basis.

Each Tenant may create one or more Environments which can be used to contain and isolate sets of PolyAPI resources in whatever manner desired–representing different services, or different teams, or even different development environments.

Most resources in PolyAPI have a visibility property which controls if the resource should be visible at the ENVIRONMENT level, or TENANT level, or PUBLIC level. Depending on the visibility set the resource will be made available for discovery and use to all API Keys of the same environment, of the same tenant, or even of the same PolyAPI instance respectively. Though a resource may be visible on a Tenant or Public level, it will still only be modifiable by API keys with the necessary permissions in the same environment.

Note

Anything created with a PUBLIC visibility is easily discoverable by ANY user from any other Tenant in the PolyAPI Instance, so should be considered truly public to anyone who’s curious.

Learn more about environments here: Environments

Users, API Keys & Permissions

Each Tenant may contain any number of Users which sit outside of Environments.

Creating a User does not immediately give them access to the resources in their Tenant. You will need to give a user an API Key in order for them to access to Poly.

API Keys are bound to a specific Environment, and has a set of granular permissions which can be used to control access to resources within the API Keys’ environment.

Learn more about authentication here: Authentication