Aller au contenu principal

Requêtes et validation

400 Bad Request​

Commencez par vérifier le Content-Type et le body réellement envoyé.

Pour une requête JSON :

Content-Type: application/json

Le fait d'écrire du JSON dans Postman ou dans votre code ne suffit pas : le header HTTP envoyé doit correspondre au contenu.

Erreur typique​

Si l'API indique qu'elle a reçu :

Content-Type: text/plain

alors que le body est du JSON, corrigez la configuration de la requête avant d'analyser le contenu fonctionnel.

Vérifier le contrat Swagger​

Pour une erreur de validation :

  1. vérifiez l'endpoint ;
  2. vérifiez la méthode HTTP ;
  3. vérifiez les headers ;
  4. vérifiez les champs obligatoires ;
  5. vérifiez les types ;
  6. vérifiez les valeurs d'énumération ;
  7. vérifiez le schéma du body.

Le Swagger SANDBOX est la référence technique.

Directory Service : paramètres et valeurs autorisées​

Le Directory Service peut renvoyer un 400 Bad Request avec le code VALIDATION_FAILED lorsqu'un paramètre, un filtre ou une valeur ne respecte pas le contrat de la route. Dans ce cas, consultez le champ errors de la réponse : il identifie le plus souvent le paramètre ou la propriété à corriger.

Exemple de structure :

{
  "status": 400,
  "code": "VALIDATION_FAILED",
  "errors": {
    "filters.property": [
      "<détail de validation retourné par l'API>"
    ]
  }
}

Pour les recherches POST /v1/siren/search et POST /v1/siret/search, vérifiez en particulier :

  • le nom exact du filtre autorisé par la route, par exemple siren, siret, businessName, name, postalCode ou administrativeStatus selon la ressource ;
  • la valeur de op : les opérateurs couramment utilisés sont strict pour une correspondance exacte et contains pour une recherche partielle ;
  • la valeur transmise : avec contains, envoyez directement la chaîne recherchée, sans * ;
  • les valeurs d'énumération : par exemple administrativeStatus: "A" désigne un établissement ou une unité légale active dans les exemples publiés.

Tous les filtres et opérateurs ne sont pas disponibles sur toutes les routes. Le Swagger/OpenAPI de la route concernée donne la liste contractuelle des propriétés et valeurs autorisées.

➡️ Recherche, filtres et pagination du Directory Service

404 Not Found​

Un 404 peut signifier que :

  • l'identifiant n'existe pas ;
  • la ressource existe mais pas dans le tenant ou le contexte fourni ;
  • l'URL est incorrecte ;
  • vous utilisez un SIREN ou SIRET à la place d'un identifiant canonique attendu par l'API.

Exemple : une route d'onboarding utilisant {legalUnitId} attend le legalUnitId retourné par la plateforme.

409 Conflict​

Un 409 indique généralement que l'opération entre en conflit avec l'état actuel de la ressource.

Avant de retry :

  • récupérez l'état courant ;
  • vérifiez si l'opération n'a pas déjà réussi ;
  • vérifiez si la ressource existe déjà ;
  • déterminez si une autre action est attendue avant de poursuivre.

413 Payload Too Large​

Vérifiez la taille du fichier ou du payload et les limites définies dans le Swagger ou la documentation du service.

422​

Un 422 indique qu'une requête syntaxiquement exploitable ne peut pas être acceptée fonctionnellement.

Examinez :

  • le détail de l'erreur ;
  • le document déposé ;
  • les règles métier applicables ;
  • le statut actuel de la ressource.

Directory Service : 204 No Content​

Pour une recherche annuaire, 204 No Content peut signifier qu'aucun résultat ne correspond aux critères transmis.

Ne le traitez pas comme une panne technique du service.

➡️ REST, JSON, erreurs et asynchronisme