- API côté serveur (
/v2/private/...) — pour les intégrations serveur à serveur de confiance. Elles retournent des données plus riches et prennent en charge les opérations d’écriture, comme les dons hors ligne et la gestion des webhooks. Ne les appelez jamais depuis un navigateur. - API côté client (
/v2/client/...) — des points de terminaison principalement en lecture (en plus du traitement des dons) qui peuvent être appelés en toute sécurité depuis des pages publiques, comme des widgets et des parcours de don personnalisés.
URL de base
Utilisez l’URL de base qui correspond à la région où votre compte est hébergé :Authentification
Chaque requête doit inclure votre clé API dans l’en-têteAuthorization. Le préfixe Bearer est optionnel.
403 Forbidden. Gardez votre clé secrète et utilisez-la uniquement depuis des environnements serveur de confiance.
Authentification de l’utilisateur
Un sous-ensemble des points de terminaison côté serveur agit au nom d’un utilisateur individuel (par exemple, pour gérer les campagnes, les équipes ou les pages personnelles qu’un utilisateur possède). Ceux-ci nécessitent un jeton utilisateur supplémentaire en plus de votre clé API.- Obtenez un jeton en appelant Sign In avec les identifiants de l’utilisateur.
- Envoyez le jeton retourné avec chaque requête spécifique à l’utilisateur, soit dans l’en-tête
auth-token, soit comme paramètre de requêtetoken.
Méthodes HTTP
L’API suit les conventions REST standards :Dates et heures
Toutes les valeurs de date et d’heure suivent la norme ISO 8601 et sont stockées et retournées en UTC. Les valeurs de date-heure sont formatées ainsi :YYYY-MM-DD hh:mm:ss.
Codes de statut
L’API utilise les codes de statut HTTP habituels pour indiquer le résultat d’une requête :Erreurs
Lorsque la validation échoue (422), la réponse liste chaque champ invalide et ses messages :
status et un message :