Use case · ePaper with Prenly

Frisbii × Prenly — the end-to-end ePaper flow

How a publisher with its own Frisbii tenant connects its readers seamlessly to the Prenly ePaper platform — without Prenly ever talking to Frisbii directly.

The bridge in four steps

A small glue service mediates between Prenly and Frisbii. Authentication and subscription data flow server-side — the app never needs to know about Frisbii.

  1. Reader app

    A reader opens the ePaper in Prenly's native app or web reader and signs in with email + password.

  2. Prenly Core

    Prenly accepts the login and asks our bridge whether the credentials are valid and which subscriptions the user holds.

  3. prenly-bridge

    Our glue service translates the Prenly Remote API into the Frisbii Media API — multi-tenant, one path per publisher.

  4. Frisbii Media

    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.

Live demo: Monthly subscription

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.

Live demo

Your ePaper — Monthly Pass

€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.

  • Frisbii Checkout for the payment flow
  • Reader unlock via Prenly + bridge
  • Access right: your-epaper-monthly (in the showcase: ammerland-kultur-monat)

Account management out of the box

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.

Why a bridge?

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.

What the bridge is not

  • Not a data store — no user profile, no token is cached.
  • Not a config server for Prenly — title mapping happens in Prenly's workspace.
  • Not an OAuth2 provider — login is verified directly against Frisbii.
  • Not a single point of failure — if it goes down, Prenly keeps serving from its 30-minute cache.