Vue d'ensemble
Les API Buzzbip utilisent des JWT via POST /api/login_check. Envoyez username et password. Le token est valide 3600 secondes. Utilisez Authorization: Bearer. Pas de refresh token. User.hasApiAccess doit être activé par un admin. Stockez les identifiants côté serveur uniquement.
Requête de connexion
Échangez vos identifiants contre un jeton Bearer via 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"}'Utilisation du jeton
Ajoutez le JWT à chaque requête protégée. Pour les plugins e-commerce, envoyez aussi x-api-key, x-platform-type et x-base-uri comme documenté dans la section secret-key. Faites pivoter les identifiants s'ils sont exposés. Réauthentifiez-vous avant l'expiration TTL d'une heure dans les jobs longue durée.
TTL JWT de 3600 secondes — réauthentifiez-vous avant expiration dans les jobs longs.
Notes d'intégration
Lors de l'intégration de ce endpoint Buzzbip, utilisez https://app.buzzbip.com comme hôte de production. Obtenez un JWT via POST /api/login_check et envoyez Authorization: Bearer sur chaque requête. Vérifiez que User.hasApiAccess est activé dans l'admin Buzzbip. Analysez les réponses JSend (status, message, data). Pour les plugins e-commerce, envoyez aussi x-api-key, x-platform-type et x-base-uri. Respectez les slashs finaux sur POST /api/contacts/ et POST /api/whatsapp/. Implémentez des nouvelles tentatives avec backoff en cas de limite de débit. Stockez les identifiants côté serveur et réauthentifiez-vous avant l'expiration du JWT (3600 s).
Sécurité
Bonnes pratiques : credentials uniquement côté serveur, TLS obligatoire, surveillance des échecs d'authentification. Séparez comptes staging et production. Documentez modèles et automatisations déclenchés. Masquez numéros et contenus dans les journaux partagés.
Et ensuite ?
Étapes suivantes : getting-started/making-your-first-request api/secret-key api/user