Use case · ePaper with Prenly
How a publisher with its own Frisbii tenant connects its readers seamlessly to the Prenly ePaper platform — without Prenly ever talking to Frisbii directly.
A small glue service mediates between Prenly and Frisbii. Authentication and subscription data flow server-side — the app never needs to know about Frisbii.
A reader opens the ePaper in Prenly's native app or web reader and signs in with email + password.
Prenly accepts the login and asks our bridge whether the credentials are valid and which subscriptions the user holds.
Our glue service translates the Prenly Remote API into the Frisbii Media API — multi-tenant, one path per publisher.
Frisbii verifies the login (verifyLogin) and returns the active access rights — these are passed back to Prenly as productCodes.
One URL per publisher (prenly-bridge.hauschild.me/<tenant>/…), one sharedKey, one Frisbii token. Onboarding a new publisher is a config update — no code change.
Real Frisbii Stage checkout, real bridge integration. Regular price €10/month — the Stage demo charges €0. After a successful purchase, the bridge verifies the unlock via GET /<your-tenant>/getUser.
€10 / month · Stage demo: €0
Monthly cancellable ePaper subscription. Regular price €10/month — the Stage demo charges €0. After purchase, the Prenly bridge unlocks reader access automatically.
For each tenant, Prenly requires three direct URLs to create, reset and delete an account — they can't embed the Frisbii SSO widget in their native app. The bridge serves these pages per publisher, branded from the tenant config, with zero custom code on Prenly's or the publisher's side.
Double opt-in: the bridge calls Frisbii, Frisbii sends a 6-digit code by email, the user confirms in the same tab.
/<tenant>/account/register Email entry, code mail from Frisbii, then code + new password in one form. We don't leak whether the email exists.
/<tenant>/account/forgot-password GDPR-compliant with login re-auth. Frisbii blocks deletion while an active subscription exists — we surface that cleanly.
/<tenant>/account/delete One tenant slug per publisher, three fixed paths — the bridge renders each page in the publisher's colors and with their imprint/privacy links:
prenly-bridge.hauschild.me/<your-tenant>/account/register prenly-bridge.hauschild.me/<your-tenant>/account/forgot-password prenly-bridge.hauschild.me/<your-tenant>/account/delete
Branding (name, logo, accent color, imprint/privacy footer) comes from TENANT_<SLUG>_BRAND_* environment variables — a new tenant means a Doppler config, not code.
Edge cases of the Prenly and Frisbii APIs are absorbed inside the bridge — Prenly sees a clean, spec-compliant interface; the publisher doesn't have to deal with corner cases.
Frisbii only allows three parallel sessions per account. From the 4th login on the API returns HTTP 207 with a removalToken — the bridge automatically calls PUT /processes/login/changeSessions/{token}, invalidates the oldest session and returns the new customerSession in the same hop. From Prenly's side it looks like a clean 200 OK.
A single Frisbii access right can unlock multiple Prenly titles. Example WZ: epaper → walsroder-zeitung + btw; wzplus → btw. The mapping table lives per tenant in Doppler as JSON, editable without a code change.
For subscriptions that have already started, publicationStart is set to null — Prenly then also unlocks issues before the subscription start (standard publishing behaviour). publicationEnd stays in place so access still ends at the real right expiry. Future-dated starts are kept as-is.
The endpoints return exactly the HTTP codes Prenly's official test suite expects — 200 / 401 / 403 / 404 / 412. Verified in the API validator and test runs A1–A5 + B1–B6.
| Code | Meaning |
|---|---|
200 | Login successful (authenticateUser) or user data delivered (getUser). |
401 | Wrong credentials — account doesn't exist or password is invalid. |
403 | Invalid sharedKey — tenant config on the Prenly side is wrong. |
404 | Unknown tenant slug (path) or unknown uid (getUser). |
412 | Required parameter missing (username/password/uid empty or not sent). |
Prenly prefers to keep its reader platform and the subscription layer separate — that means no direct reads from the publisher's subscription system. Instead, Prenly defines a narrow remote-API interface that the publisher implements themselves.
Anyone running Frisbii Media would normally have to build this themselves. Our prenly-bridge handles that: a multi-tenant service that provides the two endpoints (authenticateUser, getUser) for any number of Frisbii tenants in parallel.