Skip to content

Connecting to an event

This page describes the organizer-facing step where an event is connected to your integration.

You should understand this connection flow so your integration can handle onboarding and recovery correctly.

Prerequisites for the organizer

The customer's user must have:

Requirement Why
They can manage integrations for the event Only users with that permission can connect or disconnect integrations for the event.
The event must belong to a verified organization Only events under verified organizations can connect integrations.

These permissions are independent of the organization-level rights used to register your integration. The person who registered the integration may or may not be the person connecting it to a given event.

Catalog and connected integrations

The organizer can browse integrations that are available to this event:

  • Integrations may appear in an organization-specific section and in the public catalog, depending on how they were published.

Each integration entry exposes the metadata needed to evaluate and connect it: name, publisher, short description, requested scopes, and privacy-policy link.

Every connection is event-specific. Connecting an integration to one event does not connect it to any other event in the same organization.

Connect - the OAuth round-trip

Connecting an integration launches the OAuth authorization flow:

https://auth.revento.app/oauth/authorize
    ?client_id={your_client_id}
    &event_id={the_event_id}
    &redirect_uri={one_of_your_registered_uris}
    &response_type=code
    &scope={space_separated_scopes_from_manifest}
    &state={csrf}
    &code_challenge={s256}
    &code_challenge_method=S256

The consent screen shows your integration name, publisher name, requested scopes, event context, and privacy-policy link.

Required scopes must be granted to complete the connection. Optional scopes can be declined. If an organizer declines program.read and your integration later calls a program.read-protected endpoint, the API returns 403 insufficient_scope with required: ["program.read"].

On Authorize, the browser redirects to your redirect_uri carrying code + state. From there you follow the OAuth: organizer connect flow to exchange the code for an installation token.

Your integration's redirect_uri is on your infrastructure. After consent, the organizer lands there first, and your integration decides how to continue the UX after the token exchange.

Connected integrations

Organizers can also see which integrations are already connected to the event and whether any action is required.

Common states include:

  • Suspended - the integration cannot be used until the suspension is lifted.
  • Removed - the integration is no longer available on the platform.
  • Reconsent required - if your integration updates its manifest to add a new required scope (see Registering an integration → After registration), the organizer must re-run the OAuth flow to grant the updated scope set. Until they do, your existing token works only for the previously granted scopes.

Disconnect

When an organizer disconnects an integration:

  1. The installation token is invalidated immediately. The next API call using that token returns 401 token_revoked.
  2. If your manifest declares data.deletion_required, Revento sends that webhook to your webhook_url after disconnection. Payload contains event_id, organization_id, and the list of scopes that were granted. Your integration is contractually expected to delete its cached copy of that event's data within 30 days. See Webhook event catalog for the payload schema.

Disconnect ends that specific (event, organization, integration) connection. Reconnecting later issues a fresh token through a fresh consent flow.

What this looks like across multiple events

The event-scope discipline matters most when a single organization runs multiple events:

Scenario Result
One organization runs events A and B, both with your integration connected Two separate installation tokens. Two webhook delivery streams. Disconnecting A leaves B running.
Same org, same event A, organizer disconnects then reconnects Old token dead. New token issued. New webhook_secret is not generated - webhook_secret is per-integration, not per-connection. Existing signatures continue to verify.
Different orgs both connect your integration to their events Independent token tuples per org. Same client_id / client_secret regardless. The token carries organization_id so your integration can route data per customer.