Introducing the GlassChat Platform API

GlassChat Team · 2026-07-17

Today we're opening up GlassChat as a platform. The Platform API lets you embed GlassChat inside your own product, provision workspaces and users from your backend, drive chat programmatically, and react to activity through webhooks — all behind a neutral, versioned surface at /platform/v1.

The whole thing was built around one rule: give integrators real power without weakening the guarantees that make GlassChat GlassChat. Your frontend loads only the hosted embed bundle, your backend holds scoped keys, and end-to-end encrypted conversations stay end-to-end encrypted.

Embed without the source code

Drop GlassChat into any page with the hosted bundle:


<script src="https://glasschat.app/embed/glasschat.embed.js"></script>
<div id="glasschat"></div>
<script>
  GlassChat.mount("#glasschat", {
    appId: "app_xxx",
    token: "short_lived_embed_token",
    baseUrl: "https://glasschat.app",
    layout: "chat-only",
    theme: { accent: "#35d7c3", radiusLg: "24px", density: "compact" },
    features: { chatList: false, calls: false, files: true }
  })
</script>

The host page receives compiled JavaScript, never GlassChat source. Customization is deliberately token-based — a safelist of colors, radii, blur, density, fonts, layout aliases, and feature flags. Every value is sanitized before it touches the DOM, so there's no arbitrary CSS or host JavaScript injection to turn into an XSS footgun. You get a chat that looks like your product, not a hole in it.

Provision from your backend

Your server talks to GlassChat with a generated API key and creates the things your product needs:


POST /platform/v1/users/resolve
POST /platform/v1/teams
POST /platform/v1/teams/:teamId/members
POST /platform/v1/teams/:teamId/members/:externalId/embed-session

You map your own user and team IDs to GlassChat entities, then mint a short-lived, scoped token for each end user. That token — an RS256 JWT pinned to a single group — is what the embed and the scoped data plane (/platform/v1/groups/:groupId/*) accept. Server API keys can provision; they can't read a user's messages. Those are different jobs with different credentials.

Keys you can actually trust

API keys are the usual place integrations go wrong, so the defaults are strict:

  • Shown once. The raw secret is returned exactly once at creation. We store only a SHA-256 hash and a non-sensitive lookup prefix.
  • Scoped. Every key carries explicit scopes (platform:provision, platform:embed, and friends). No scope, no access.
  • Managed from the dashboard. Create apps, set allowed origins and themes, issue and revoke keys — all from the admin Platform tab, which never exposes the platform admin secret to the browser.

Signed webhooks, delivered properly

Subscribe an HTTPS endpoint to events and GlassChat delivers a signed envelope with an HMAC signature over a timestamp and body, so you can verify authenticity and reject replays:


x-glasschat-signature: t=<unix>,v1=<hmac_sha256(timestamp.body)>

Deliveries retry with backoff on 5xx, 429, and timeouts, cap out after five attempts, and record a full delivery history — status codes and sanitized errors, never your endpoint's response bodies or the signing secret. Webhook URLs must be HTTPS with no credentials and no private-network destinations. The signing secret, like API keys, is shown once and encrypted at rest.

Plans, quotas, and rate limits

Because this is a paid surface, billing is built in — and it fails closed. Each app has a billing status and optional monthly limits; past_due and suspended block generated keys, and an exhausted quota returns platform_quota_exceeded. Each app also has an optional per-minute request cap: bursts over the limit get a fast platform_rate_limited response before they ever reach the quota check. A 0 limit means zero — never accidental unlimited.

The E2EE line we won't cross

This is the part we care about most. GlassChat's end-to-end encrypted chats are ciphertext the server can't read, and the Platform API doesn't change that. Server responses and webhooks never expose decrypted content for E2EE conversations. When a workflow genuinely needs plaintext — a bot that reads and replies — it runs in a clearly marked business-automation chat where everyone understands the boundary. The default is always E2EE-safe.

Getting started

The full reference lives in the Platform API docs: endpoints, scopes, embed options, webhook events, and the security defaults behind all of it. If you've been running against the older /partner/v1 routes, they still work and now carry deprecation headers — migrate when you're ready.

We're excited to see what you build on top of GlassChat.