Registering an integration¶
The publisher's entry point. Open your organization in Revento, go to Settings → Integrations, click New integration, fill in the manifest form, and store the credentials issued at creation time.
This page walks the form field-by-field.
Prerequisites¶
| Requirement | Why |
|---|---|
| You can manage integrations for the organization | This grants access to the integrations settings area and the manifest form |
| The organization is verified to publish integrations | Only verified organizations can register and publish integrations. |
If either requirement is missing, registration cannot be completed. Ask an organization owner or admin to grant access, or complete organization verification first.
The manifest form - 14 fields¶
The form has six sections. Section headers below match the page; field names are the canonical manifest keys.
Identity¶
| Field | Type | Constraints | What it controls |
|---|---|---|---|
display_name |
string | max 80 chars | The integration name shown in the catalog and on consent screens. |
description |
string | max 500 chars | Long-form copy on the integration detail page. |
tagline |
string | max 120 chars, optional | One-line summary shown on catalog cards. Falls back to a shortened description if empty. |
logo |
file | PNG, 512×512, max 512 KB | Icon shown on catalog cards, consent screens, and connected-app views. Files outside these constraints are rejected. |
Publisher¶
| Field | Type | Constraints | What it controls |
|---|---|---|---|
publisher_name |
string | max 80 chars | Shown as the publisher name on catalog and consent screens. |
support_email |
string | required, valid email | Where Revento sends operational notices for this integration. Use a monitored shared address, not a personal one. |
publisher_website_url |
string | HTTPS, optional | Link on integration detail page. Plain marketing/info URL - not a redirect URI. |
Permissions & data access¶
| Field | Type | Constraints | What it controls |
|---|---|---|---|
declared_scopes |
array of {name, required: bool} |
subset of the published scope catalog; each scope marked required or optional |
The set of scopes your integration is ever allowed to request at OAuth time. You cannot request a scope at /oauth/authorize if it isn't in this list - Revento responds invalid_scope. required: true means the organizer cannot decline; required: false means the scope is shown with a checkbox the organizer can uncheck. Adding a new scope after launch triggers re-consent on every existing connection. |
The published scope catalog includes event.read, participants.read, program.read, profile.read, and event.attendance. See Scopes for descriptions and flow-specific behavior.
Webhooks - optional¶
| Field | Type | Constraints | What it controls |
|---|---|---|---|
declared_webhook_event_types |
array | subset of the published webhook event types, or empty | If empty: no webhooks. The webhook_url field becomes optional and you receive no deliveries. If non-empty: webhook_url becomes required. Adding new event types later updates the manifest; there are no per-event-type subscription endpoints. |
webhook_url |
string | HTTPS, required if event types declared | The single endpoint to which Revento posts every webhook for every (event, organization, integration) tuple. Revento performs a one-time HTTPS reachability check during registration and expects a 2xx response. |
OAuth & legal¶
| Field | Type | Constraints | What it controls |
|---|---|---|---|
redirect_uris |
array of strings | 1–10 entries, HTTPS, exact match (no wildcards) | The whitelist Revento checks against the redirect_uri parameter at /oauth/authorize. http://localhost:3000/callback and http://localhost:3000/callback/ (trailing slash) are different URIs - register every variant you actually use. Tunnel URLs (ngrok, cloudflared) change between sessions unless you have a stable subdomain; re-register the new URL each time, or use a stable staging subdomain. |
privacy_policy_url |
string | HTTPS, required | Linked on consent screens and the catalog detail page. Required because users must be able to read your privacy policy before granting consent. |
System fields¶
| Field | Type | Source | What it controls |
|---|---|---|---|
visibility |
enum | publisher-chosen at registration | organization-only - only your organization's events can install it. public - intended for catalog distribution beyond your own organization. |
organization_id |
string | auto-filled | The publishing organization. For organization-only integrations, this also bounds which events can install them. |
What you get on submission¶
On submission, Revento validates the manifest and, if webhook_url is set, verifies that the endpoint is reachable over HTTPS.
On success, Revento issues three values:
| Value | Sensitivity | Notes |
|---|---|---|
client_id |
Public identifier | Goes in your OAuth client config. Visible on the edit page afterwards. |
client_secret |
Confidential | Used for confidential-client OAuth + server-to-server calls. Shown once at creation time. |
webhook_secret |
Confidential | Used to verify HMAC signatures on incoming webhook deliveries. Shown once at creation time. Only shown if you declared webhook event types. |
Store the secret values before you close the dialog. Treat them like any other production credential.
If you lose the credentials¶
You can rotate either secret directly via the developer-tooling endpoints:
POST /developer/integrations/{integration_id}/rotate-client-secret
POST /developer/integrations/{integration_id}/rotate-webhook-secret
Both endpoints support a 24-hour dual-validity overlap: the old secret remains valid for 24 h after rotation, and Revento signs webhook deliveries with both during the overlap (under two distinct header names - X-Revento-Signature and X-Revento-Signature-Previous; see Verifying signatures). This lets you roll out the new value to your fleet without a hard cutover.
Secret rotation may be rate-limited.
After registration: editing vs republishing¶
Most fields can be edited in-place on the integration detail page - display_name, description, tagline, logo, publisher_name, support_email, publisher_website_url, privacy_policy_url, webhook_url, redirect_uris. Edits take effect immediately for new OAuth flows.
Two changes have stronger semantics:
| Change | Effect |
|---|---|
Adding a new scope to declared_scopes |
Every existing connection enters "re-consent required" state. Existing tokens continue to work for the previously granted scopes; new scope is gated until each organizer re-consents. Re-consent is always an explicit OAuth round-trip. |
Adding a new webhook event type to declared_webhook_event_types |
Deliveries for the new type start flowing immediately to your existing webhook_url, signed with your existing webhook_secret. No additional action on existing connections. |
Visibility changes after registration may be restricted.
Cross-links¶
- Connecting to an event - what your customer's organizer sees once you've registered.
- OAuth: organizer connect - the wire-level flow that follows the Connect button click.
- Scopes - scope table and descriptions.
- Webhooks overview - webhook delivery model and operational expectations.
- Going to production - the operational checklist before real customers connect.