Copy as Markdown Open in ChatGPT Open in Claude llms.txt

Webview pages

A webview page is a top-level event-navigation entry that loads your integration's URL inside an iframe (web) or platform webview (mobile). Use this when your integration's UX is best delivered inside the Revento app rather than as a standalone web destination.

Examples that fit this shape:

• An interactive map of the convention venue
• A live program / schedule view that updates as activities go on
• A feedback form that adapts to the participant's session
• A real-time chat channel for a specific event

Examples that don't:

• Bulk data sync to a CRM (no UX needed inside Revento)
• An email sender (acts on data, doesn't render UI)
• Anything that wants to deeply interact with the Revento app shell (we don't allow that)

How it differs from a regular external link

A static page can have an external link button. A webview page is different in three ways:

	External link button	Webview page
Rendering	Opens in new tab	Embedded in the Revento UI
Auth	None	Optional Login-with-Revento round-trip
Lifecycle	Just a URL	First-class page type with permissions, visibility, archival

If you're thinking "a webview page is an iframe," you're right. The framework handles the chrome (event header, back button, sandbox) so you focus on rendering content.

Adding a webview page

The organizer adds it from the event admin panel:

1. Open "Event pages" → "New page"
2. Pick page type "Webview"
3. Fill in:
   • Title — what shows in event navigation
   • URL — your integration's URL that will be embedded
   • Auth required — checkbox, see below
   • Visibility — participants, organizers, etc.
4. Publish

Once published, the webview page appears in event navigation alongside static pages, with the same visibility rules.

The organizer needs webview_page.create (and webview_page.edit to modify it later). Connecting an auth-required webview to your integration additionally requires integration.manage on the event.

Auth-required vs not

requires_auth: no

Your URL is loaded in an iframe with no Revento credentials passed. The participant's Revento session is not shared with you. Use this when your content is public — a static map, a schedule rendered server-side without personalization.

requires_auth: yes

Tapping the page kicks off Login with Revento automatically. The participant goes through the OAuth round-trip (silent if previously consented), and your integration receives a user token. After authentication, your URL is loaded in the iframe with whatever auth shape you implemented (typically a session cookie set by your callback).

The flow:

sequenceDiagram
    actor P as Participant
    participant R as Revento app
    participant Y as Your backend
    participant I as Iframe (your URL)

    P->>R: Tap webview page in event nav
    R->>R: Check participant has<br/>active session for your integration
    alt First time
        R->>P: Show consent screen (full screen)
        P->>R: Authorize
        R->>Y: OAuth callback with code
        Y->>R: User token issued
    end
    R->>I: Load your URL in iframe
    Note over I: Your iframe-rendered<br/>page reads its own session

For first-time consent, the consent screen is rendered inline (full-screen replacing the webview), not as a modal over your iframe. After consent, the iframe loads.

For warm path (participant previously consented), the entire OAuth round-trip happens silently and the iframe loads in well under 1.5 seconds on a 4G connection (best-effort target — actual cold-start can be 2–3s on slower networks).

Sandbox directives

Web webview pages are rendered as iframes with these attributes:

<iframe
  src="{your URL}"
  sandbox="allow-scripts allow-same-origin allow-forms allow-popups"
  referrerpolicy="strict-origin-when-cross-origin">
</iframe>

The CSP header on the iframe response includes frame-ancestors matching the integration's declared origins.

What's allowed

• allow-scripts — your page can run JavaScript.
• allow-same-origin — your page can read/write its own cookies, localStorage, etc.
• allow-forms — your page can submit forms.
• allow-popups — your page can open new windows (e.g. for external auth like Stripe Checkout).

What's NOT allowed

• allow-popups-to-escape-sandbox — popups inherit the same sandbox; they can't break out.
• allow-top-navigation — your page cannot navigate the parent (Revento app) window.
• allow-modals — alert() / confirm() are blocked. Use your own UI for confirmations.

Mobile webview equivalent

On mobile, the iframe is replaced with the platform's native webview control. The HTML sandbox attributes don't apply directly — instead, the framework configures equivalent restrictions:

• JavaScript: enabled
• Navigation: only allow within your registered origin's path; off-origin navigation is blocked or routed to the platform browser
• Top-level navigation hijacking: blocked
• Native popups (alerts): blocked
• Third-party cookies: blocked by default

The default mobile posture is restrictive.

Server-side considerations for your URL

Your URL is loaded inside an iframe (web) or webview (mobile). A few things to handle:

CSP frame-ancestors

Your response should explicitly allow Revento as a frame-ancestors:

Content-Security-Policy: frame-ancestors https://app.revento.example

Without this, browsers may refuse to load your page in the iframe (depending on legacy X-Frame-Options headers your stack might emit).

Cookies and storage

Inside the iframe, your origin's cookies and localStorage are accessible. The participant's Revento session is not shared — if you need participant identity, you go through Login with Revento and store your own session cookie tied to your integration.

Responsive layout

The iframe sizes follow Revento's layout. On mobile that's typically 100% × visible viewport; on desktop the page area minus navigation chrome. Don't assume a specific pixel dimension — use viewport units and flex.

Navigation chrome

Revento renders the event header and back button outside the iframe. You don't render your own. Your page's content fills the iframe area without any "back to event" button.

Common pitfalls

• Embedding a page that sets X-Frame-Options: DENY. Browsers refuse to render it. Use frame-ancestors CSP and don't emit X-Frame-Options from the iframe origin.
• Assuming you can read the participant's Revento cookie. You can't — different origin. Use Login with Revento.
• Calling window.parent.someMethod(). Sandbox blocks it. Don't try to interact with the Revento app from your iframe.
• Building a UX that needs alert() or confirm(). They're blocked. Use modals you render inside your iframe.
• Forgetting mobile. Test in the actual Revento mobile app — the mobile webview has platform-specific behaviors that don't always match the desktop iframe.

Restrictions

• No top-frame navigation. Your iframe cannot redirect the participant out of Revento.
• No access to other event content. The iframe sees only your URL and its descendants.
• No persistent presence. Each navigation reloads the iframe; no cross-page state without your own backend.
• No file system access (web) or device APIs beyond what the platform mobile webview exposes.

If your integration genuinely needs deeper integration than this — accessing camera, push notifications via Revento, etc. — that's a feature conversation, not something a webview page can do.