Introduction

Bloonio Relay is the shared integration layer of the Bloonio platform. It exposes two generic, tenant-agnostic “relay” products:

Auth Relay — delegated strong authentication (device pairing, approval push, QR login, “sudo” step-up, passkeys).
Chat Relay — multi-tenant chat and tickets (web widget, in-app SDK, human operators, webhook callbacks, self-service console).

Both relays are built to plug into any backend, much like a third-party identity provider: your application becomes a tenant of the relay, and everything flows through a single integration contract.

Why a shared hub

Auth Relay and Chat Relay deliberately share the same architecture:

a shared tenants collection and one provisioning lifecycle;
one HMAC signing scheme (same headers, same computation) for every backend → relay call;
the same universal validator, relay_user_id (the “Stripe Connect” model), linking a user to multiple tenants without cross-tenant leakage;
SDKs in a common shape (Python today, more to come).

Learn the model once on the Platform concepts pages, then apply it on both sides.

Tenancy & relay_user_id The tenancy model and the universal validator.

Authentication (HMAC) The signing recipe, shared by both relays.

Tenant lifecycle Provision, rotate secrets, suspend.

Webhooks & callbacks Receive signed events on your backend.

Where to start

Integrating authentication? Start with Auth Relay — Quickstart.
Integrating chat? Start with Chat Relay — Quickstart.
New to the platform? Read Tenancy & relay_user_id first.

Documentation conventions

Request examples use a $BASE_URL placeholder to be replaced with the base URL of the relay in question. We never hardcode an internal gateway host.
Secrets are always placeholders (tnt_..., sk_...) — never commit them.
Each relay’s API reference is generated from its OpenAPI specification; it is the authoritative source for exact schemas.