Getting Started
This guide takes you from zero to your first Bizgate Partner API call.
Use it to understand what Bizgate is, how authentication works, how to obtain credentials, and how rate limits and errors behave before you explore the full API Reference.
Base URL (production): https://partner.gupshup.io/partner/bizgate
Introduction to Bizgate
Bizgate is Gupshup’s partner platform for WhatsApp Business API integrations. It gives partners APIs and portal tools to onboard customers, manage WABA apps, send messages, and operate at scale.
With Bizgate you can:
- Integrate Bizgate Partner APIs into your own product or branded UI
- Manage apps, templates, profiles, wallets, and onboarding via REST
- Use the Bizgate Partner Portal for operational workflows
- Optionally offer a white-labeled Bizgate Partner Customer Portal to your customers
Partners are typically Independent Service Providers (ISVs) or Tech Providers (TPs) building WhatsApp solutions on top of Gupshup.
New to the partner program? Start with Get Started as a Partner, then return here for API authentication and your first request.
Path to your first API call
| Step | What to do |
|---|---|
| 1 | Get partner access and ensure Bizgate is enabled for your account |
| 2 | Obtain a Universal Token (UT) — see Obtaining API Keys |
| 3 | Call a Bizgate endpoint with Authorization: Bearer <UT> |
| 4 | Handle success and error responses — see Error Codes |
1. Authentication
Every authenticated Bizgate request must carry a Universal Token in the Authorization header:
Authorization: Bearer <Universal Token>| Type | Format | Purpose |
|---|---|---|
| Universal Token (UT) | Signed JWT with tt=UT, sub=partnerId | Cross-service auth. Long-lived, used for all Bizgate integrations. |
Public routes (for example login, signup, and Swagger/docs surfaces) do not require auth.
Treat the Universal Token like a secret. Do not commit it to source control or expose it in client-side code.
2. Obtaining API Keys
| Credential | How to obtain |
|---|---|
| Universal Token (UT) | Contact the Gupshup platform team for onboarding — they provision a UT bound to your partnerId (sub claim). The token is long-lived; store it securely and pass it on every request as Authorization: Bearer <UT>. |
After you have a UT:
- Pick an endpoint from the Bizgate API Reference
- Send a request to
https://partner.gupshup.io/partner+ the endpoint path - Include the
Authorization: Bearer <UT>header
Example:
curl -X GET \
"https://partner.gupshup.io/partner/bizgate/app/{appId}/profile" \
-H "Authorization: Bearer <Universal Token>" \
-H "Accept: application/json"Replace {appId} and <Universal Token> with your values.
3. Rate Limits
Bizgate applies per-endpoint, per-caller sliding window rate limits. When a limit is exceeded, the API returns 429 Too Many Requests.
| Tier | Typical cadence | Applied to |
|---|---|---|
| 3 / minute | Very sensitive ops (e.g. password resets) | Auth-mutation endpoints |
| 5 / minute | Sensitive mutations | e.g. updateSpecificAppSubscription |
| 10 / minute | Standard write ops | e.g. decideAppLinkRequest, linkAppBySsToken |
| 10 / second | High-throughput read/message ops | e.g. getBlockedUsersList, template send |
| 20 / minute | Moderate ops | Selected admin flows |
| 30 / minute | Standard reads / lookups | e.g. partner-link-token (GET+POST), listAppLinkRequests |
| 60 / minute | Frequent polling | Selected status endpoints |
Design retries with backoff when you receive 429. Endpoint-specific limits may also be documented on individual API reference pages.
4. Error Codes
All error responses share this shape:
{
"status": "error",
"message": "<human-readable>"
}| HTTP | When |
|---|---|
| 200 | Success. Response body is endpoint-specific (Response { status, message, data } for most Bizgate handlers). |
| 400 Bad Request | Invalid request body/params (missing fields, malformed UUIDs, unknown enum values). |
| 401 Unauthorized | Missing / invalid / expired token. Also returned when signature or issuer does not verify. |
| 403 Forbidden | Authenticated, but the caller lacks the required role for this endpoint (e.g. PARTNER_ADMIN-only routes called by PARTNER_USER). |
| 404 Not Found | Resource not found; or Bizgate is not enabled for the caller's partner (BIZGATE_ENABLED missing). |
| 409 Conflict | Duplicate resource, or state mismatch (e.g. app-link request no longer PENDING). |
| 429 Too Many Requests | Rate limit exceeded — see Rate Limits for cadence tiers. |
| 500 Internal Server Error | Unhandled server-side failure. Includes a correlation-safe generic message; server logs carry the trace. |
5. Webhooks Overview
Webhooks are HTTPS callbacks that deliver inbound WhatsApp messages and message status events to your platform in real time.
When a customer messages your WhatsApp Business number — or when a message you sent is sent, delivered, read, or fails — Gupshup posts an event to the callback URL configured for that app.
Why set up webhooks
| Use case | What you receive |
|---|---|
| Inbound messaging | Text, media, location, and other user messages |
| Delivery receipts | Sent, delivered, read, and failed statuses |
| Out-of-band events | Account, template, and other app-level notifications (depending on subscription modes) |
How to configure
- Expose a publicly reachable HTTPS endpoint that can receive
POSTrequests - Create a subscription for your app with a callback URL — see All subscription APIs
- Choose the event modes/versions your integration needs
- Acknowledge each notification quickly, then process the payload asynchronously
Common subscription operations:
| Action | Endpoint |
|---|---|
| Create subscription | POST /bizgate/app/{appId}/messaging/subscription |
| List subscriptions | GET /bizgate/app/{appId}/messaging/subscription |
| Get / update / delete by id | GET / PUT / DELETE .../messaging/subscription/{subId} |
| Subscribe inbound webhook/event | POST /bizgate/app/{appId}/configuration/subscription |
All of these require Authorization: Bearer <UT>.
Webhook requirements
| Requirement | Guidance |
|---|---|
| Respond with 2xx | Return HTTP success (2xx) with an empty body. If you do not respond within 10 seconds, Gupshup treats the delivery as failed and retries. |
| Acknowledge fast | Process messages asynchronously. Aim to acknowledge in under 100 ms when possible; 500–1000 ms is typically acceptable. |
| Public access | Your webhook URL must be reachable from the internet. |
Accept User-Agent | Your endpoint should accept the HTTP User-Agent header. |
| IP allowlisting | Optionally whitelist Gupshup inbound IPs. Contact [email protected] for the current IP list. |
For deeper webhook setup details, see Webhooks & Callback and Webhook Key Points. For API Try It pages, open Subscription APIs.