Skip to content

Participants authorizing your integration

Only relevant if your integration implements Login with Revento - i.e. participants sign into your app using their Revento account and you receive a user token bound to (user, event, integration).

If your integration is purely server-to-server (only reads event data via the installation token), participants are never directly involved and you can skip this page.

For everyone else, this page explains the participant-side authorization and revocation flow.

The participant's first sign-in

Your app exposes a "Sign in with Revento" button. The participant taps it; you launch the standard OAuth authorization flow against https://auth.revento.app/oauth/authorize with their user-scoped scopes (typically profile.read and event.attendance).

The Revento consent screen shows your integration name, publisher, requested scopes, event context, privacy-policy link, and approve/cancel actions.

If the participant isn't logged into Revento, they hit the Revento login page first, then land on the consent screen.

Eligibility - when can a participant sign in at all

A participant can sign into your integration via Login with Revento only if they are associated with at least one event where your integration is connected. Otherwise, authorization fails before consent and no token is issued.

The eligible-events picker

If a participant is attending multiple events that your integration is connected to, the consent screen shows them which event the resulting token will be bound to. The user token carries event_id as a claim - your integration knows which event the participant is signing in for. The participant cannot sign in once and have it cover all their events: every token is bound to one event, and a participant who attends 5 events that all have your integration connected can produce 5 separate user tokens (one per event) if they sign in 5 times.

If they want a unified view across events, your integration is responsible for stitching the per-event tokens together on your side (e.g. "this user has tokens for events A and B; we'll show their data from both"). Revento provides separate tokens, not a cross-event identity.

Token and refresh semantics

After consent the participant is redirected back to your redirect_uri with a code. Exchange it at /oauth/token for:

  • A user access token (~1 h lifetime).
  • A refresh token (90-day sliding window, 1-year hard cap).

User tokens carry event_id and sub (user ID) always; email + name are added only when profile.read was granted. event.attendance discloses only attendance confirmation - no application status, no roles. See Login with Revento for the full token shape and refresh recipe.

A user with application_status: rejected (or pending, revision_requested) can still sign in successfully - event.attendance covers any non-cancelled application. If your integration needs to differentiate by status (e.g. gate features on approved), read the participant record via your installation token's GET /events/{id}/participants and correlate by user_id.

Participant revocation

Participants can review and revoke previously authorized app connections from their Revento account settings.

Revocation is scoped to a single (integration, event) authorization. Revoking access for event A does not affect the participant's tokens for the same integration on event B.

When a participant revokes:

  1. The user token (and any associated refresh token) is invalidated immediately.
  2. If your manifest declares user.revoked_access, Revento sends that webhook after revocation. Payload identifies which (user, event, integration) tuple was revoked.
  3. The integration's next API call with that token returns 401 token_revoked.

You should treat user.revoked_access as your primary signal - don't poll for it. Subscribe in your manifest's declared_webhook_event_types and react to the webhook.

What you control vs what you don't

You control You don't control
Which scopes your manifest declares (and which you mark required) Whether the participant grants them
The copy on your /auth/sign-in page that drives them to "Sign in with Revento" The hosted consent-screen experience apart from the integration name, logo, publisher info, and privacy-policy URL
Receiving and reacting to user.revoked_access When or whether the participant revokes
Cross-event correlation on your side Whether the participant signs in to your integration on event A vs event B vs both