Connecting your integration

You wrote the code. Now what does it take for your integration to actually reach an event's data?

Three roles matter in this flow: the publisher, the event organizer, and, if your integration uses user sign-in, the participant.

sequenceDiagram
    autonumber
    actor P as Publisher (you)
    actor O as Event organizer
    actor U as Participant
    participant R as Revento

    P->>R: Register integration
    R-->>P: client_id + client_secret + webhook_secret
    O->>R: Start event connection
    R-->>O: OAuth consent screen
    O->>R: Authorize (granted scopes)
    R-->>P: Installation token (your backend, server-to-server)
    Note over P,R: Integration can now read event data
    U->>P: Click "Sign in with Revento"<br/>(only if you implement Login with Revento)
    P->>R: /oauth/authorize for user token
    R-->>U: Consent screen (scopes for THIS user)
    U->>R: Authorize
    R-->>P: User token (per (user, event, integration))

Three things to internalize before reading the rest:

1. You register your integration once, per organization - same client_id and client_secret for every event your integration is ever connected to. There is no "test" pair vs "production" pair. See Registering an integration.

2. An organizer connects your integration per event. Every connection issues a fresh installation token bound to one (event, organization, integration) tuple. Disconnecting from event A has no effect on event B even if both belong to the same organization. See Connecting to an event.

3. A participant only enters the picture if your integration implements Login with Revento. Their token is bound to (user, event, integration) - also per-event. The participant authorizes you on their own, after the organizer has connected you. See Participants authorizing your integration.

Who registers an integration

The publisher. That is: someone who can manage integrations for a verified organization in Revento.

Integration type	Who registers it	Where
Organization-only - only this org will install it	An org admin from that org	In the organization's integration management area
Public - intended for distribution beyond the publishing org	A publisher with a verified organization	In the publishing organization's integration management area

For a customer-specific integration, the customer organization should own the registration and credentials.

Who does what

The three roles interact with the integration in different ways:

Role	What they do
Publisher-side administrator	Registers the integration, manages its manifest, and rotates secrets.
Event organizer	Connects or disconnects the integration for a specific event.
Participant	Authorizes or revokes user access if your integration uses Login with Revento.

You build against the OAuth flow, API, and webhook contract, but your users still experience the integration through these separate roles and actions.

The publisher's first hour, in order

If you're starting today:

1. Make sure you (or someone on your team) can manage integrations for a verified organization. If not, Before you start covers the prerequisites.
2. Register your integration - Registering an integration.
3. Store the issued credentials securely.
4. Create a draft event in your org (or use an existing one). Connect your integration to it - Connecting to an event.
5. The OAuth flow runs. You receive an authorization code, exchange it for an installation token. From there you're in the OAuth: organizer connect flow.
6. If your integration is participant-facing, implement Login with Revento and verify the participant journey in Participants authorizing your integration.

Use a draft event to test these steps before connecting the integration to a live customer event. The same OAuth host, API host, and webhook contract apply in both cases.

What you DON'T need to do

• You don't approve event-side connections. Once your integration is available to an organization, authorized event organizers in that organization can connect it to their events without your involvement.
• You don't seed test data. Test against your own org's draft events, or against a customer's draft event if the customer has added you as an organizer.
• You don't manage participant tokens on the participant's behalf. If your integration is participant-facing, participants authorize themselves through Login with Revento; you receive the resulting token and store it. If a participant later revokes access in Revento, your integration receives user.revoked_access and the next API call with that token returns 401 token_revoked.