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; afterwards we only store its hash
Webhook signing secret	One per integration, rotatable	Used to verify that webhook deliveries genuinely came from Revento

You'll also have access to:

A developer console — view your integration's metadata, registered redirect URIs, webhook delivery log, dead-letter queue, audit log of token issuance.
A sandbox environment with pre-seeded test events, organizations, and participants.

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 (registered tax identifier such as NIP). Organizations that aren't verified can't authorize integrations and don't see an integrations panel.

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.

Sandbox vs production¶

Your client_id / client_secret work in either sandbox or production based on the OAuth endpoint URL you hit. You'll have separate credentials for each environment so a bug in dev can't accidentally affect a real event.

	Sandbox	Production
OAuth base	`https://auth.revento.example/oauth/...` (same as production)	`https://auth.revento.example/oauth/...`
API base	`https://api.revento.example/api/v1/...` (same as production)	`https://api.revento.example/api/v1/...`
Test data	Pre-seeded, resettable	Real organizer data — be careful
Rate limits	Same as production	See Rate limits

Sandbox URLs above are placeholders.

Your account contact shares the real sandbox URLs when access is provisioned.

Once you have what you need¶

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