Skip to main content
We built EpisBox so you can ship an AI-powered product without a security review on your critical path. Auth, tokens, credentials, billing — we own all of it. You write a <script> tag and a <div>. That’s your entire security surface.

​
Your clientId is meant to be public

Your clientId is a public identifier — designed to be in your HTML source, exactly like Google’s OAuth client_id or Stripe’s pk_live_... publishable key. It tells our servers which app is embedding EPIS, nothing more.
There is no clientSecret on your side. No private key. No signing.
Origin-restriction enforcement (rejecting a clientId used from a domain you didn’t register) is on our roadmap but not yet live — today, clientId identifies your integration to us for support and analytics, not as a security boundary. Don’t rely on it to keep your integration private; there’s nothing sensitive to protect on your side either way (see below).

​
We handle auth — completely

The “Authenticate with PastpaperLM” flow runs entirely on our infrastructure:
1

User clicks Sign In

A popup opens on our domain — our servers, our Google OAuth credentials. Users sign in with the same PastpaperLM account they already use everywhere else.
2

Google auth runs

The entire OAuth exchange happens between the user, Google, and PastpaperLM. Your app is not in the loop.
3

Token lands in the iframe

The access token is posted to embed.pastpaperlm.com via postMessage — stored in the iframe’s own localStorage, scoped to our origin. Your page can’t read it. It’s not yours to manage.
4

EPIS loads

The user is authenticated. Popup closes. Chat appears. You didn’t write a single line of auth code.

​
Tokens live in the iframe — not your page

EpisBox uses localStorage keyed to embed.pastpaperlm.com. That means:
  • Tokens are isolated to the iframe’s origin by the browser’s same-origin policy
  • Your JavaScript can’t access them — not accidentally, not intentionally
  • Safari ITP, Firefox ETP, Chrome’s third-party cookie blocking — none of these affect localStorage. Your users stay signed in across sessions on every browser
We also handle token refresh for you: access tokens are long-lived (multi-day), and if one ever does expire mid-session, the SDK transparently exchanges it for a fresh one on the next request — no dropped session, no re-login prompt, no code on your side.

​
iframe isolation — your app and EPIS don’t bleed into each other

EPIS runs in a sandboxed <iframe> from embed.pastpaperlm.com. The browser enforces a hard boundary:
  • Your CSS doesn’t affect the EPIS UI — theme it with our token system, not global stylesheets
  • EPIS can’t read your page’s DOM, cookies, or localStorage
  • A bug in EPIS can’t XSS your app. A bug in your app can’t reach EPIS internals
The only bridge between your page and EPIS is postMessage — and the SDK validates the origin of every message. Messages from unexpected origins are silently dropped.

​
Billing is ours too

Your users are billed directly by PastpaperLM. Payment details, credit card numbers, subscription state — none of it passes through your domain. You don’t handle a payment integration; you earn a revenue share on usage we track and pay out monthly.
PCI compliance, GDPR data processing agreements, and payment security — these are our problems. You get the revenue share without the compliance burden.