Overview
Buzzbip APIs use JSON Web Tokens (JWT) obtained from POST /api/login_check. Send your Buzzbip username and password in the request body. On success you receive a token string valid for 3600 seconds (one hour). Include it on subsequent requests as Authorization: Bearer <token>. There is no refresh-token endpoint — re-authenticate when the token expires. Most /api routes also require the account flag User.hasApiAccess to be enabled by an administrator in /admin. Without API access, authenticated calls return an authorization error even with a valid JWT. Store credentials and tokens server-side only; never expose them in browser code or public repositories.
Login request
Exchange credentials for a bearer token using the login_check endpoint.
curl -X POST 'https://app.buzzbip.com/api/login_check' \
-H 'Content-Type: application/json' \
-d '{"username": "your_username", "password": "your_password"}'Using the token
Add the JWT to every protected request. For ecommerce plugin integrations, also send x-api-key, x-platform-type, and x-base-uri headers as documented in the secret-key section. Rotate credentials immediately if a token is exposed. Schedule re-authentication before the one-hour TTL in long-running background jobs.
JWT TTL is 3600 seconds — schedule re-authentication before expiry in long-running jobs.
Integration notes
When integrating the Buzzbip authentication endpoint into your application, treat https://app.buzzbip.com as the only production host. Obtain a JWT from POST /api/login_check and send Authorization: Bearer <token> on every request. Confirm User.hasApiAccess is enabled in Buzzbip Admin — without it, valid tokens still receive authorization errors. Parse JSend responses by reading status, message, and data together; do not rely on HTTP status codes alone. For ecommerce plugins, also send x-api-key, x-platform-type, and x-base-uri as described in the secret-key documentation. Respect trailing slashes on routes such as POST /api/contacts/ and POST /api/whatsapp/. Implement retries with exponential backoff when you encounter rate limits, and log full error bodies during development. Store credentials server-side, rotate secrets if exposed, and re-authenticate before the 3600-second JWT TTL expires in long-running workers. Use pagination query parameters instead of unbounded list calls, and queue bulk WhatsApp or SMS sends from your backend rather than client browsers. Test against a small set of contacts before enabling production campaigns. Keep an integration runbook that lists which Buzzbip templates, automations, and API keys each deployment uses so on-call engineers can diagnose failures quickly.
Security
Security best practices for Buzzbip API clients include restricting API credentials to backend services, using TLS for every request, and monitoring failed authentication attempts. Separate staging and production Buzzbip accounts when possible so template tests do not message real customers. Document which templates and automations each integration triggers, and version your webhook or sync job deployments. When debugging, redact phone numbers and message bodies in application logs shared with third parties.
What's next?
Next steps: getting-started/making-your-first-request api/secret-key api/user