API Authentication

Zoho Backstage APIs use OAuth 2.0 for authentication. This page gives you an overview of the authentication process. For complete details on OAuth 2.0 flows, registration, token management, and more, refer to Zoho OAuth 2.0 documentation.

How it works

To access Zoho Backstage APIs, your application needs an access token obtained through one of the OAuth 2.0 flows. At a high level, the steps are:

1. Register your application in the Zoho API console.
2. Get consent from user to access their data and obtain an access token.
3. Call Zoho Backstage APIs using the access token.

Token expiry: Access tokens expire periodically. The expiry duration is mentioned as expires_in (seconds) in the access token response. To maintain uninterrupted access, you can request for an optional refresh token, store it, and use it to generate new access tokens as needed.

Different OAuth flows for different app types: Zoho supports OAuth flows for different application types (server-based, client-based, mobile & desktop-based, limited input devices, and self client). You can choose the flow that matches your application.

Multi DC support: Zoho operates data centers in multiple regions. If your application serves users across regions, you must enable Multi DC support in the API console and use region-specific endpoints for both OAuth and Product API calls.

See detailed OAuth 2.0 workflow

Scopes

Zoho Backstage APIs require OAuth scopes to define the level of access your application needs. When requesting for access token, request only the scopes your application requires. These will be displayed to the users when asking for consent.

To request multiple scopes, separate them with commas: scope=ZohoBackstage.portal.READ,ZohoBackstage.exhibitor.READ

For more details about scope format, see OAuth Scopes.

Making API calls with access token

To authenticate your API calls, include the access token in the Authorization header of every API request.

Supported formats:

Authorization: Zoho-oauthtoken <space> {access-token-value}
Authorization: Bearer <space> {access-token-value}

Example

curl -X GET "https://www.zohoapis.com/backstage/v3/portals/{portal_id}/events/{event_id}"

-H "Authorization: Zoho-oauthtoken 1000.abc123def456..."

API endpoints by data center

When making API calls, you must use the base URL corresponding to your user's data center. The correct URL is returned as api_domain in the access token response.

Important: Never hardcode a single region's URL. Always use the api_domain from the access token response. See Multi-DC Support

Zoho Backstage-specific requirements

Portal ID and Event ID

Zoho Backstage APIs are designed around a portal > event hierarchy, and most API operations require both identifiers to scope the request correctly.

• portal_id: The unique identifier of your Zoho Backstage portal. All events, users, and configurations exist within a portal.
• event_id: The unique identifier of an event within the portal. Each API operation is executed in the context of a specific event.

These identifiers are typically included as path parameters in API endpoints and ensure that requests are routed to the correct portal and event.

Without the correct portal_id and event_id, API requests cannot be processed.

Module-based access

Zoho Backstage APIs are organized into event-level modules, and access to each module is controlled using OAuth scopes.

Each module represents a functional area of your event, such as:

• Events: Basic event details and configuration
• Agenda: Sessions, tracks, and scheduling data
• Exhibitors: Exhibitor profiles, booths, and requests
• Speakers: Speaker profiles and session associations
• Registrations: Attendees, tickets, and order data

Scopes define what actions your application can perform within these modules, such as:

• READ – Retrieve data
• CREATE – Add new records
• UPDATE – Modify existing data
• DELETE – Remove data

For example:

• ZohoBackstage.speaker.READ allows read-only access to speaker data
• ZohoBackstage.exhibitor.CREATE allows creating exhibitor records

Access is granted only to the modules and actions explicitly defined in the requested scopes. If a required scope is not included, the API request will be denied.

Related resources about OAuth

• Registering your app in API console
• OAuth glossary
• Token limits
• Incremental authorization
• Sign in using Zoho (OIDC)