Partner Authentication Guide: Universal Tokens (UT) Overview
1. Current Authentication Approach
Today, partners use multiple credential types depending on the integration model, APIs, and operational use case.
The Legacy Workflow
Previously, a partner had to manage split authentication flows:
- Flow A:
Client Secret➔ GeneratesPartner Token➔ GeneratesPartner App Token(Valid only for Bizgate Partner APIs). - Flow B: Generate
App API Keyand/orAccount-level API Key(Valid only forapi.gupshup.ioAPIs).
The New Unified Workflow
In the new model, the authentication flow is completely unified:
Client Secret➔ Generates Universal Token (UT) (Valid for all Bizgate Partner APIs + allapi.gupshup.ioAPIs).
Authentication Concepts & Definitions
1.1 Client Secret
A Client Secret is used as part of partner authentication and integration workflows. It is generated individually by any partner admin or non-admin user and must be stored securely.
- New Secrets: Newly regenerated client secrets have a maximum validity of 3 months.
- Legacy Secrets: Existing, never-expiring client secrets remain unchanged for now (updates to this behavior are planned for future security enhancements).
- Expiry Reminders: Currently on the product roadmap.
1.2 Partner Token
Used to generate/retrieve a Partner App Token or to fetch all partner apps within onboarding APIs.
- Generation: Created using a user's Client Secret.
- Deprecation Notice: The legacy method of creating a partner token using just the Bizgate Partner Portal password is now deprecated.
- TTL / Expiry: 24 hours.
1.3 Partner App Token (PAT)
Used for partner-level API authentication specifically for the https://partner.gupshup.io/ endpoint.
- Constraints: Only one PAT can exist at any given time.
- Generation: Can be generated by both admin and non-admin users via the Bizgate Partner Portal UI or API.
- TTL / Expiry: Long-lived.
- Scope: Works at the app level for all apps linked to the partner.
1.4 Account API Key
Provides authentication at the Gupshup account level (including app level) and is commonly used across https://api.gupshup.io/ endpoints.
- Scope: Not restricted to a single app; has global scope for a given Customer ID. Used to authenticate any apps present in a given Customer ID, whether linked to a partner or not.
- TTL / Expiry: Long-lived.
- Availability Note: No longer exposed or passed on to new Customer IDs since March 2026.
1.5 App API Key
Generated at the application level and scoped to a specific app. Commonly used across https://api.gupshup.io/ endpoints.
- Constraints: A maximum of 2 active app-level API keys per app can exist concurrently.
- Scope: Strictly restricted to a single app (authenticates the app whether it is linked to a partner or not).
- TTL / Expiry: Long-lived.
2. New Authentication Method
The future authentication model streamlines access control around a simplified set of credentials while phasing out legacy types.
| Supported Mechanism | Phasing Out |
|---|---|
|
|
Universal Tokens (UT)
Universal Tokens (UT) provide a unified, secure, and simplified authentication mechanism for partner-linked applications. By adopting Universal Tokens, you eliminate the overhead of managing multiple split API keys, reducing security risks and streamlining integration management.
NOTE : It does not work apps not linked to your partner ID.
Key Characteristics
- Unified Access: Works seamlessly across all apps linked to a partner. Validates requests for both
https://api.gupshup.io/andhttps://partner.gupshup.io/across all API endpoints. - Admin-Controlled: Only administrators can generate or revoke UTs via the UI (API management is planned). Automated email alerts are triggered to notify admins of any generation or revocation activities.
- Token Limits: A maximum of 3 active Universal Tokens are allowed at any one time per partner. It means that when you want to rotate the first universal token, you can create a second UT while the first UT keeps running. Once you have made your integration changes with the second UT, you can retire the first UT.
- Flexible Expiry: Configurable validity between a minimum of 24 hours and a maximum of 60 days. Partners are responsible for rotating tokens prior to expiration.
- Non-Disruptive Migration: UTs work concurrently alongside legacy App tokens and API keys. Once you have successfully verified your UT integration, you can disable legacy mechanisms to minimize security exposure without breaking active operations.
Steps to Generate a Universal Token
Prerequisites
- Your user account must have Admin access on the Gupshup Bizgate Partner Portal.
- The Universal Token configuration section becomes available only after completing the initial Security Wizard steps up to the 'Client Secret' phase. See the Bizgate Partner Portal Security Wizard Guide for details.
- Universal token works only for apps linked to your partner ID.
Generation Workflow
The generation and consumption of a Universal Token is completely non-disruptive to active live operations.
- Navigate to the Settings section in the Bizgate Partner Portal.
- Open the Universal Token Management section.
- Click on Generate Universal Token.
- Configure your preferred token expiry duration (between 24 hours and 60 days).
- Confirm token generation.
- Copy and securely store the generated token immediately.
Critical Security NoteUniversal Tokens are displayed only once during generation and will not be accessible via the UI later. These tokens are meant exclusively for partner-side integrations and must never be shared with customers or exposed in client-side code.
UI Walkthrough
- Locate the Universal Token panel in your account configuration:

Best Practice: Naming TokensName your Universal Tokens based on their environment or operational purpose (e.g.,
QA-Environment,Staging-Token,Prod-Sync). We recommend utilizing shorter expiry durations for non-production or temporary testing use cases.
-
Set the token name and expiry window:


-
View and safely copy the token:

-
Revoke a token instantly if it is compromised or no longer needed:

-
Confirm access revocation:

Automated System Notifications
Whenever a token action occurs, administrators will receive automated confirmation emails:
-
Creation Alert:

-
Revocation Alert:

Important LimitationUniversal Tokens will not authenticate endpoints pointing to
/sm. Please transition away from these pathways by following the /sm Endpoints End-of-Life Deprecation Guide.
Disabling Legacy Authentication Mechanisms
After establishing and validating your Universal Token integration, you should systematically deprecate old credentials. If unexpected downtime or issues occur, the portal allows you to Undo the deprecation instantly to restore legacy traffic.
Recommended Migration Approach
Phase 1 – Parallel Usage
Partners may initially:
- Continue using existing API keys and tokens
- Validate all workflows using UT
- Ensure operational stability
Phase 2 – Controlled Migration
Once UT usage is validated:
- Disable Account API Keys
- Disable App API Keys
- Disable Partner App Tokens
Steps to Disable Legacy Keys
Navigate to your Universal Token Security Settings panel to manage toggles for legacy formats:
Deactivating Account API Keys
-
Toggle off Account-level authorization:

-
Confirm deactivation:

-
Optional: if rollback is required click Reactivate Gupshup account API keys

Deactivating App Level API Keys
- Click Deactivate App level API keys


Deactivating Partner App Tokens (PAT)
-
Turn off the primary legacy Partner App Token toggle:

-
Confirm system impact:

Conclusion
Migrating to Universal Tokens yields a significantly safer, unified, and transparent authentication lifecycle. Once legacy parameters are successfully disabled by a platform admin via the Bizgate Partner Portal, older credentials will immediately fail authentication requests across all partner-linked applications, preventing unauthorized external access.
Updated about 1 month ago