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 depends on direct integration with Revento's surrounding UI or native app behavior

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

Revento provides the surrounding navigation and security restrictions; your page only needs to render its content.

Adding a webview page

Organizers can add a webview page to an event by providing a title, URL, auth requirement, and visibility.

Once published, the page becomes available in the event according to its visibility rules.

The organizer needs permission to create and edit event pages. Connecting an auth-required webview to your integration additionally requires permission to manage integrations for that 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: If needed, initiate authentication
    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 participant completes the consent flow before the iframe loads. If the participant already consented for the same event, the OAuth round-trip can complete without another consent screen.

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, Revento loads the page in a native webview with restrictions equivalent to the web embedding model. Test mobile behavior in the Revento app.

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 the Revento app origin as a frame-ancestors value:

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

https://app.revento.example is illustrative here. Use the actual origin provided in your integration setup surface. Without a matching frame-ancestors, 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

Available space varies by device and layout, so the page should be responsive.

Navigation chrome

Revento provides surrounding navigation outside the embedded page.

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; any cross-page state is your responsibility.
• No file system access (web) or device APIs beyond what the platform mobile webview exposes.

If your integration needs deeper native or shell-level integration, that is outside the scope of webview pages.