Skip to content

Before you start

A pre-flight checklist. Read this once before the quickstart - it'll save you time.

What you'll need

Tooling on your side

  • An HTTP client. Anything - curl, Postman, Bruno, your language's stdlib. The quickstart uses Node + fetch but the contract is language-agnostic.
  • A way to receive HTTP callbacks. Specifically:
    • An OAuth redirect_uri - a URL on your server that Revento will redirect to after consent, carrying an authorization code. During development a tunnel like ngrok or cloudflared works fine; in production this is a stable HTTPS endpoint you control.
    • A webhook endpoint - an HTTPS URL where Revento POSTs event notifications. Same shape, same tunnels in dev.
  • The ability to verify an HMAC-SHA256 signature. Stdlib in every language; we walk through the exact recipe in Webhooks → verifying signatures.
  • A place to store secrets. Your client_secret, your webhook signing secret, and the access + refresh tokens you'll be issued. Database with at-rest encryption, or a secrets manager. Don't put them in env vars committed to git.

What we'll give you

When you register your integration with Revento, you'll receive:

Credential Lifetime What it's for
client_id Forever Identifies your integration in OAuth requests
client_secret Forever (rotatable) Authenticates token-exchange requests. Shown to you once at registration, so store it securely.
Webhook signing secret One per integration, rotatable Used to verify that webhook deliveries genuinely came from Revento

You'll also have access to integration management tools for maintaining settings and reviewing webhook delivery status.

What we'll need from you

Before issuing your credentials we need:

  • Publisher info - display name, website URL, support contact.
  • Declared scopes - the exact set of scopes your integration will ever request. Adding a new scope later requires every existing connection to re-consent (see Scopes → versioning), so think this list through.
  • Declared webhook event types - which events you'll ever subscribe to. Same logic - adding more later is fine but not free.
  • Redirect URIs - exact-match list of URLs we'll allow as OAuth redirect_uri parameters. Wildcards are not supported.
  • Webhook URL - single URL we'll POST to. Optional if your integration only polls or only renders webview pages.

We'll also need to know which type your integration is:

  • Public - listed in the Revento catalog, any formal organization can connect it.
  • In-house - private to one specific formal organization, not visible in the public catalog.

Restrictions you should know up-front

These will not surprise you later if you read them now.

Only formal organizations can authorize integrations

A "formal organization" in Revento is a verified legal entity. Organizations that aren't verified can't authorize integrations.

Organizations that aren't verified must complete verification before they can connect any integration.

Per-event binding is non-negotiable

You can't get one token that works across every event an organization runs. Every event needs its own connection and its own consent screen. See the mental model.

PKCE is required for every client type

Both public clients (no client_secret, e.g. mobile apps that authenticate participants) and confidential clients (server-to-server, with client_secret) must include PKCE parameters in the authorization request. There's no pkce: optional flag. The library you use almost certainly handles this for you; we mention it now because if you write the OAuth handshake by hand and skip the code_challenge parameter, you'll get invalid_request: PKCE required.

The API is read-only

If your design assumes "the integration writes back to Revento at this point", redesign around that assumption.

One set of credentials, any event

Your integration has one client_id / client_secret from registration; they authenticate the integration regardless of which event you connect it to. When testing, connect your integration to an event you control and use the standard OAuth flow. The same credentials, endpoints, and contract apply when another organizer later connects the integration to their event.

See Registering an integration for the registration form, and Connecting to an event for what happens when an organizer attaches your integration to one of their events.

Once you have what you need

Head to the quickstart. End-to-end working integration in about 30 minutes.