La sécurité de vos données et de votre accès à l'API est primordiale. Suivez ces règles pour éviter tout usage non autorisé.

• Ne jamais exposer vos identifiants : Ne codez jamais en dur votre API_TOKEN ou votre SECRET_KEY dans votre code source, surtout s'il est public. Utilisez des variables d'environnement ou un gestionnaire de secrets (comme HashiCorp Vault, AWS Secrets Manager, etc.).
• Renouveler vos clés régulièrement : Pensez à régénérer vos clés depuis le dashboard périodiquement ou en cas de suspicion de compromission.
• Configurer des origines (CORS) strictes : Dans la section "Domaines autorisés", ne déclarez que les domaines de vos applications qui doivent légitimement appeler l'API. N'utilisez pas de jokers (*) sauf si c'est absolument inévitable.
• Utiliser un User-Agent descriptif : L'en-tête User-Agent est obligatoire. Utilisez une valeur qui identifie votre application (ex: MonAppRH/2.1).

Une utilisation efficace de l'API garantit de meilleures performances et évite les blocages.

• Utiliser les endpoints de masse : Pour publier ou modifier plusieurs offres, privilégiez les endpoints "en masse" (ex: /jobs-posting) plutôt que d'envoyer une requête par offre. Cela réduit la latence et le risque d'atteindre les limites de débit.
• Gérer les limites de débit (Rate Limiting) : Si vous recevez une erreur 429 Too Many Requests, votre code doit cesser d'envoyer des requêtes pendant un certain temps. Implémentez une stratégie de "backoff exponentiel" (attendre 1s, puis 2s, puis 4s, etc.) avant de réessayer.
• Contrôler la taille des requêtes : La taille maximale du corps d'une requête est de 3 Mo. Si vous envoyez des données en masse, assurez-vous de ne pas dépasser cette limite (erreur 413 Payload Too Large).

La pertinence de vos offres dépend de la qualité des données que vous envoyez.

• Fournir des données complètes : Pour optimiser la visibilité de vos offres, fournissez le maximum de champs disponibles. Une offre bien renseignée est mieux référencée et plus attractive. Consultez la Référence des champs.
• Valider côté client : Avant d'envoyer une requête, validez les formats (dates, emails), la présence des champs obligatoires et la logique métier (ex: salary_min ne peut pas être supérieur à salary_max). Cela réduit les erreurs 400 et 422.
• Privilégier JSON : Bien que XML soit supporté, le format JSON est recommandé pour sa légèreté et sa facilité de manipulation dans la plupart des langages modernes.
• Attention aux spécificités XML : Si vous utilisez XML, assurez-vous de ne pas avoir de balises dupliquées pour un même champ et faites attention à l'indentation qui peut invalider le document. Utilisez un générateur (DOMDocument, XDocument) pour plus de sécurité.

Une intégration robuste doit anticiper et gérer les erreurs correctement.

• Journaliser les erreurs : Logguez systématiquement les requêtes échouées, leur corps et la réponse d'erreur de l'API. Cela est essentiel pour le débogage.
• Gérer les erreurs 5xx (serveur) : Ces erreurs (500, 502, 503) sont temporaires. Votre code devrait être capable de réessayer la requête après un court délai (voir backoff exponentiel).
• Ne pas réessayer les erreurs 4xx (client) : Ces erreurs indiquent un problème avec votre requête. La réessayer sans la corriger échouera à nouveau et consommera votre quota. Corrigez le problème (données invalides, authentification, etc.) avant de renvoyer.

L'idempotence garantit que si vous envoyez la même requête plusieurs fois, l'opération ne sera effectuée qu'une seule fois. C'est crucial pour éviter de créer des offres d'emploi en double.

• Utiliser un identifiant unique externe : Le champ id de l'offre est votre référence unique. L'API renverra une erreur 409 Conflict si vous essayez de créer une offre avec un id qui existe déjà.
• Gérer les erreurs de réseau : Si vous envoyez une requête de création, mais que vous ne recevez pas de réponse (timeout, etc.), ne la renvoyez pas aveuglément. Avant de réessayer, effectuez une requête GET sur l'endpoint de listing ou de détail pour vérifier si l'offre a bien été créée entre-temps.

Avant de passer en production, il est fortement recommandé de tester votre intégration dans un environnement isolé. L'API EasyJobs fournit un environnement sandbox complet à cet effet.

• Environnement de test sécurisé : le sandbox vous permet d’envoyer des requêtes réelles sans impacter vos données de production. C’est l’endroit idéal pour déboguer votre code et valider le comportement de votre application.
• Consultez la documentation du mode Sandbox pour valider vos intégrations dans un environnement contrôlé et sans risque.