Panoramica
Le API Buzzbip usano JWT da POST /api/login_check. Invia username e password. Token valido 3600 secondi. Usa Authorization: Bearer. Nessun refresh token. User.hasApiAccess deve essere abilitato dall'admin.
Richiesta di accesso
Scambia le credenziali per un token Bearer tramite l'endpoint login_check.
curl -X POST 'https://app.buzzbip.com/api/login_check' \
-H 'Content-Type: application/json' \
-d '{"username": "your_username", "password": "your_password"}'Utilizzo del token
Aggiungi il JWT a ogni richiesta protetta. Per plugin e-commerce invia anche x-api-key, x-platform-type e x-base-uri come nella sezione secret-key. Ruota le credenziali se esposte. Ri-autenticati prima del TTL di un'ora nei job long-running.
TTL JWT 3600 secondi — riautenticati prima della scadenza nei job lunghi.
Note di integrazione
Integrando questo endpoint Buzzbip, usa https://app.buzzbip.com come host di produzione. Ottieni un JWT da POST /api/login_check e invia Authorization: Bearer su ogni richiesta. Verifica che User.hasApiAccess sia abilitato nell'admin Buzzbip. Analizza le risposte JSend (status, message, data). Per i plugin e-commerce, invia anche x-api-key, x-platform-type e x-base-uri. Rispetta gli slash finali su POST /api/contacts/ e POST /api/whatsapp/. Implementa retry con backoff in caso di rate limit. Conserva le credenziali lato server e riautenticati prima della scadenza JWT (3600 s).
Sicurezza
Best practice: credenziali solo lato server, TLS obbligatorio, monitoraggio autenticazioni fallite. Separa account staging e produzione. Documenta template e automazioni. Redigi numeri e contenuti nei log condivisi.
Prossimi passi
Passi successivi: getting-started/making-your-first-request api/secret-key api/user