L’authentification requiert un token Bearer et une secret key à fournir dans les en-têtes HTTP
Authorization et Usersecretkey. Pour la sécurité de ces clés, consultez nos bonnes pratiques de sécurité.
Dans votre espace Mon compte → API, utilisez les boutons « Nouveau token » ou « Nouvelle secret key ». Attention : la clé précédente devient immédiatement invalide. Mettez à jour vos intégrations avant de continuer l’envoi.
Nous mettons à votre disposition un environnement Sandbox complet pour tester votre code sans impacter vos données de production. C'est le moyen recommandé pour valider votre intégration. Pour plus de détails, consultez la page Sandbox.
L'API supporte les deux formats. Cependant, nous recommandons d'utiliser JSON car il est plus léger et plus facile à manipuler dans la plupart des langages de programmation modernes. Pour plus d'informations, consultez la section sur la qualité des données.
Les principaux plafonds sont :
- Taille maxi du corps JSON / XML : 3 Mo
- Limite d’appels : 100 requêtes/min par IP, 1000 requêtes/h par token
429 Too Many Requests avec l’en‑tête Retry‑After. Détails dans la page Limites et restrictions.
Ces erreurs indiquent un problème avec les données que vous envoyez. Une erreur
400 Bad Request signifie souvent que votre JSON / XML est malformé. Une erreur 422 Unprocessable Entity signifie que la syntaxe est correcte, mais que les données sont incohérentes (ex: salary_min > salary_max). Validez vos données avant de les envoyer, comme expliqué dans nos bonnes pratiques et consultez la référence des erreurs.
Une erreur
429 Too Many Requests signifie que vous avez dépassé les limites de requêtes autorisées. Vous devez mettre en pause vos appels et attendre avant de réessayer. Implémentez une stratégie de "backoff exponentiel" comme recommandé dans nos bonnes pratiques d'optimisation.
Pour éviter les doublons, utilisez un identifiant unique (
id) pour chaque offre que vous envoyez. Si vous tentez de créer une offre avec un id qui existe déjà, l'API retournera une erreur 409 Conflict. C'est ce qu'on appelle l'idempotence. Apprenez-en plus dans nos bonnes pratiques sur l'idempotence.
Le endpoint
/job-posting permet de publier une seule offre, tandis que /jobs-posting est un endpoint de masse (bulk) pour publier plusieurs offres en une seule requête. Utiliser les endpoints de masse est une bonne pratique pour l'optimisation. Voir la section Optimisation des requêtes.
L'en-tête
User-Agent est obligatoire. Utilisez une valeur qui permet d'identifier clairement votre application, par exemple MonAppRH/2.1. C'est une règle de sécurité importante, comme mentionné dans nos bonnes pratiques.
Nous fournissons une collection officielle Postman ainsi que des exemples prêts à l’emploi en PHP, Python, C# et JavaScript.
Vous pouvez les retrouver dans la page Téléchargements, ou accéder à des exemples d’intégration détaillés pour chaque endpoint via la section Exemples d’intégration.
- Mise à jour : endpoint
job‑edit(PUT) oujobs‑editpour les mises à jour en lot. - Suppression : endpoint
job‑delete(DELETE) oujobs‑delete.
id et les champs à modifier ; les champs obligatoires vides conservent leur ancienne valeur.
Utilisez le format strict : nombre + symbole + période, par exemple :
30000€/an15€/heure
salary_min et salary_max doivent utiliser la même période (an, mois, heure...). Consultez Référence des champs pour les regex exactes.
L’API est actuellement en version
v1. Nous n’introduisons pas de ruptures sans annoncer une version majeure v2. Les changements mineurs (nouveaux champs, améliorations) sont rétro‑compatibles et annoncés dans le changelog.
Pour toute question non couverte par la documentation, écrivez‑nous à support@easyjobs.fr.
Copyright EasyJobs API © 2025 - Tous droits réservés