Espace développeurs 🛠

Voici la liste des fondamentaux techniques à mettre en place pour le bon fonctionnement de l’API Entreprise :

• ☑️ Être en mesure de gérer le protocole HTTPS ;
• ☑️ Avoir une version de langage récente. Si vous utilisez Java, une version >= 1.8 est nécessaire (pour la gestion des certificats de +1024 bit, du TLS 1.2 minimum et des suites cryptographiques - ciphers) ;
• ☑️ S’assurer que nos Autorités de Certification (AC) pour les certificats SSL sont autorisées par vos systèmes ;
• ☑️ L’API Entreprise est uniquement accessible par internet. Si vous avez un pare-feu, il faut donc prévoir de whitelister l’adresse IP du service API Entreprise ;
• ☑️ Il est interdit d’interroger l’API Entreprise depuis un site web en front-end, car le jeton d’accès serait alors divulgué. Il vous faut donc interroger nos API depuis une application en back-end. Nous n’autoriserons pas le CORS (CORS - Cross Origin Ressource Sharing) ;
• ☑️ Prévoir non seulement les coûts de développement mais également les coûts de maintenance ;
• ☑️ Être en capacité de gérer les mises à jour de l’API Entreprise.

💡 Pour mieux comprendre l’API Entreprise avant de demander un accès, vous pouvez utiliser notre environnement de test.

Les plafonds

Les limites de volumétrie sur API Entreprise se décomposent en deux règles principales : 

• Un plafond général par IP de 1000 requêtes/minute.

• Une volumétrie par jeton par groupe d’endpoints :
  - 1er groupe : Les endpoints renvoyant du JSON constituent un premier groupe. Vous pouvez effectuer jusqu’à 250 requêtes/min/jeton sur ce groupe.
  - 2ème groupe : Les endpoints transmettant des documents constituent un autre groupe. La volumétrie maximale d’appel concernant ce groupe est de 50 requêtes/min/jeton.
  - Exceptions : Certains endpoints échappent à cette règle et présentent une volumétrie spécifique par endpoint. Il s’agit notamment de l’API attestation fiscale de la DGFIP, de l’API dépréciée Actes de l’INPI ou encore des API effectifs du GIP-MDS. Comme pour toutes les API du bouquet, la volumétrie exacte figure dans le header.

Informations volumétrie dans le header

Pour toutes les réponses :

Dans toutes les réponses de nos API, le header vous transmet des informations sur la volumétrie :

Exemple :
Considérons un endpoint ayant une limite de 50 appels /minute.
Vous faîtes un premier appel à 10h00 pile, et effectuez un second appel 20 secondes plus tard, puis un troisième 10 secondes plus tard, vous aurez les valeurs suivantes :

• RateLimit-Limit : 50 ;
• RateLimit-Remaining : 47 (50 moins les 3 appels effectués) ;
• RateLimit-Reset : [Timestamp correspondant au jour présent à 10h01]. Le premier appel initialise le compteur (à 10h00 pile), la période se termine 1min plus tard.

Vous pouvez donc jusqu’à 10h01 pile effectuer 47 appels, le compteur sera réinitialisé à 50 à ce moment-là.

En cas de dépassement :

Si vous dépassez le nombre d’appels autorisés (RateLimit-Remaining = 0), le serveur répondra avec le status 429 sur tous les appels suivants dans la même période.

Le header associé à ce code erreur 429 sera accompagné : 

• des trois champs précédents ;
• d’un champ supplémentaire indiquant le temps à attendre avant de pouvoir effectuer des nouveaux appels.

Vous pouvez donc utiliser les champs du header pour optimiser votre consommation de l’API Entreprise.

Règles de bannissement en cas de surconsommation

En cas de non prise en compte des codes erreurs 429 ou en cas de dépassement de la limite de volumétrie globale, votre IP sera temporairement bannie de nos serveurs pour une durée fixe et non révocable de 12h. Si vous avez plusieurs jetons, tous seront donc bloqués pendant ce laps de temps.

Les appels depuis une IP bannie ne renvoient pas de codes HTTP, le serveur ne répond tout simplement pas.
Vous pouvez en revanche vérifier si vous avez dépassé ce seuil depuis votre compte utilisateur.

ℹ️ Au bout de ces 12 heures, vos accès sont automatiquement rétablis ; il est donc inutile d’écrire au support.

Nous vous invitons à prendre les mesures nécessaires car le dépassement intervient généralement chez nos utilisateurs lorsque leur programme n’a pas été correctement configuré.

Pour les appels de traitement de masse, il est souhaitable que vous fassiez vos batchs automatiques la nuit ou durant les heures creuses afin de ne pas affecter la qualité du service pour le reste des usagers.

Le timeout est le temps d’attente maximal de réponse à une requête. Il vous permet de ne pas immobiliser votre logiciel en le laissant bloqué sur un appel sans réponse.

De façon générale, nous vous recommandons un timeout : 

• de 5 secondes pour les appels de données structurées JSON ;
• de 12 secondes pour les appels retournant un PDF ou un ZIP.

De même, pour ne pas immobiliser nos serveurs, nous attendons les réponses de nos fournisseurs un maximum de 10 secondes avant de vous les retransmettre. Si ce délai d’attente est dépassé un code erreur HTTP 504 vous sera renvoyé.

API Entreprise utilise DHIMYOTIS comme organisme de délivrance de ses certificats SSL principaux ainsi que Let’s Encrypt pour certains services secondaires.

Il est conseillé d’ajouter ces Autorités de Certifications (AC) à votre base de confiance si vous en avez une. Une solution idéale est d’utiliser un paquet d’autorités mises à jour automatiquement (Mozilla par exemple)

API Entreprise utilise des certificats multi-domaines ; c’est-à-dire avec un “nom courant” (common name - CN) et plusieurs “noms alternatifs du sujet” (subject alternatives names - SAN), soyez certains que vos outils fonctionnent correctement avec.

Un code standard HTTPS pour catégoriser le statut de l’appel

Toutes les réponse de l’API Entreprise sont envoyées avec un code HTTPS. Ces codes permettent de se renseigner sur le statut de l’appel, et sont harmonisés pour l’ensemble des API quelque soir le fournisseur de données.
Pour en savoir plus sur les codes HTTPS, cet article de Wikipedia constitue une bonne base explicative.

En cas de succès, le code HTTP commence par 2 :

En cas d’échec, si l’erreur vient de votre côté, le code HTTP commence par 4 :

En cas d’échec, si l’erreur provient d’API Entreprise ou bien des fournisseurs de données, le code HTTP commence par 5 :

Un code supplémentaire pour préciser l’erreur et enclencher une action

Tous les codes erreur HTTPS sont accompagnés de codes plus précis, spécifiques à chaque situation d’erreur. Une explication en toutes lettres est également donnée dans la payload. Enfin, dans certains cas, une métadonnée actionnable est disponible.

Dans l’exemple ci-dessous, la clé retry_in permet justement de relancer un appel après le nombre de secondes indiquées.

Exemple de payload d’un code HTTPS 502 :

{
   "errors": [
      {
           "code": "04501",
           "title": "Analyse de la situation du compte en cours",
           "detail": "La situation de l'entreprise requiert une analyse manuelle d'un agent de l'URSSAF. Une >demande d'analyse vient d'être envoyée, cela prend au maximum 2 jours.",
           "meta": {
               "provider": "ACOSS",
               "retry_in": 172800
          }
       }
   ]
}

Retrouvez tous les codes erreurs pour chaque endpoint dans notre swagger, partie “Response samples”.
La liste des codes spécifiques à chaque endpoint y est disponible.

API Entreprise vous permet d’accéder à des données protégées. C’est pourquoi, dans un objectif de traçabilité, nous vous demandons de renseigner dans chacune de vos requêtes, non seulement un jeton d’accès, mais aussi certaines informations qualifiant votre requête.

⚠️ Ces paramètres sont obligatoires. Les appels ne comportant pas ces paramètres sont rejetés, et un code erreur vous est renvoyé.

Pour chaque endpoint, nous précisons dans le swagger, rubrique “Query parameters” les paramètres obligatoires spécifiques, ci-dessous une explication détaillée des éléments à fournir pour chaque paramètre de traçabilité :

Il est fréquent que les API évoluent et que, par conséquent, de nouvelles versions soient publiées.
La version majeure V.3 de l’API Entreprise permet de créer facilement de nouvelles versions, tout en gardant les précédentes, rendant ainsi accessibles rapidement les évolutions qu’API Entreprise obtient de ses fournisseurs.

Toute évolution implique une montée de version

Les montés de version d’une API interviennent pour toute évolution, c’est-à-dire :

• l’ajout d’un nouveau champ par le fournisseur de la donnée ;

  Par exemple : Ajout du champ “économie sociale et solidaire” lors d’une évolution mineure par l’Insee.

• la transformation de la structure de l’API par le fournisseur de la donnée ;

  Par exemple : Sortie d’une évolution majeure chez le fournisseur donnée.

• l’ajout d’une fonctionnalité par API Entreprise

  Par exemple : Délivrance d’un nouveau champ “Certification valide” pour une API qui ne renvoyait avant que l’URL de téléchargement de l’attestation.

Pour comprendre comment monter en version, consultez la rubrique suivante.

Les anciennes versions maintenues tant que le fournisseur de la donnée le permet

Depuis la V.3 de l’API Entreprise, les anciennes versions sont maintenues par le service API Entreprise tant que cela est possible.
En pratique, cela signifie que :

• tant que le fournisseur continue d’envoyer la strcuture de données de l’ancienne version, cette ancienne version est maintenue par l’API Entreprise ;
• si le fournisseur ne renvoie plus la même structure de donnée, API Entreprise supprimera l’ancienne version car la maintenir reviendrait à renvoyer des champs vides.

Depuis la version 3 de l’API Entreprise, toutes les API peuvent évoluer indépendamment les unes des autres. Les anciennes versions (à partir de la V.3) restent donc toujours disponibles si le fournisseur de la donnée continue de transmettre les informations.
Depuis la version 3, le numéro de version est un paramètre de l’appel et non plus une valeur fixe pour toutes les API comme en version 1 et 2 (Les versions 1 et 2 sont définitivement dépréciées).

Exemple d’utilisation du paramètre d’appel de version :
Imaginons un exemple fictif : l’API documents, cette API est disponible en v.3 et une nouvelle version est sortie, la V.4.
Pour appeler la version souhaitée, il vous faudra directement inscrire le numéro de la version dans l’URL : https://entreprise.api.gouv.fr/v3/... pour la V.3 ou https://entreprise.api.gouv.fr/v4/... pour la V.4.

📩 Une lettre d’information annonce systématiquement les nouvelles évolutions. Vous pouvez vous abonner ici.

API Entreprise met à disposition un ensemble de routes de “pings” permettant de récupérer l’état des services fournis par les différents fournisseurs de données.
L’ensemble des routes est disponible à l’adresse suivante: Routes de pings (format JSON).

Pour chacune de ces routes, l’équipe d’API Entreprise effectue des vérifications spécifiques au fournisseur, permettant d’être au plus près de la réalité quand à la santé dudît fournisseur.
Chacune de ces routes renvoi un json sous le format suivant:

{
  "status": "ok",
  "last_update": "2023-11-03T12:24:07.185+01:00",
  "last_ok_status": "2023-11-03T12:24:07.185+01:00"
}

Avec:

• status, string, qui peut avoir 3 valeurs: ok quand tout est OK, bad_gateway quand il y a un souci, unknown quand on ne peut pas déterminer le status ;
• last_update, datetime, date de la dernière mise à jour: pour éviter de surcharger nos systèmes nous effectuons de la mise en cache sur les pings ;
• last_ok_update, datetime, date de la dernière mise à jour en OK: permet de savoir depuis quand le service est en défaut.

A noter que le status http est à 200 pour ok et unknown, 502 pour bad_gateway : cela permet à nos systèmes de monitoring de ne pas lever d’alertes en cas de données insuffisantes (et ainsi éviter des potentiels faux positifs).

Nous vous conseillons de passer par ces routes de surveillances, et ceci pour plusieurs raisons:

1. API Entreprise s’occupe de la complexité vis-à-vis de la disponibilité de certains partenaires (limitation sur le nombre d’appels sur certains identifiants, échecs aléatoires etc..) ;
2. Il n’y a pas de limitations sur ces routes
3. L’implémentation est plus simple que d’utiliser les routes officieles
4. Un bad gateway d’une route de ping a de forte chance d’être un vrai positif, contrairement à un échec sur les endpoints qui peut être dû à des erreurs réseaux/temporaires.

Pour connaître la liste des APIs auxquelles vous avez le droit avec votre jeton d’accès, vous pouvez le vérifier avec l’API /privileges.

Si vous gérez les tokens pour vos utilisateurs, vous pouvez aussi utiliser cette API pour vérifier les droits associés à leurs tokens.

La requête HTTP :

https://entreprise.api.gouv.fr/v2/privileges?token=LeTokenATester

Le paramètre d’appel à renseigner est le token dont vous souhaitez connaître les droits.

Exemple de réponse JSON :

{
 "privileges": [
   "attestations_agefiph",
   [...]
   "actes_bilans_inpi"
 ]
}

La réponse JSON renvoie la liste des API autorisées. Retrouvez-leurs spécifications techniques dans le Swagger.

L’API Entreprise propose un environnement de test ou bac à sable pour vous permettre de tester le branchement de l’API avec votre système d’informations.

💡 L’environnement de test est une fonctionnalité à destination des usagers techniques. Si vous êtes un profil métier, veuillez vous référer aux fiches métier de chaque API disponibles depuis le catalogue.

Les informations essentielles du bac à sable :

• Une URL : L’‘environnement de staging est appelable avec https://staging.entreprise.api.gouv.fr.

• Les jetons d’accès : Pour être fidèle au fonctionnement de l’API en production, cet environnement de test nécessite aussi un jeton d’accès, mais celui-ci, contrairement aux jetons de production, est public car la donnée renvoyée en bac à sable est fictive. Un jeton ayant tous les droits est accessible ici. Pour générer un jeton spécifique, veuillez vous référer à ce tutoriel.

• Les données fictives de réponse : Les données retournées par cet environnement de test sont totalement fictives et disponibles depuis ce dépôt.

• Pour rappel, le fichier OpenAPI est disponible depuis le swagger, avec le bouton “Download” situé en début de page.

Pour en savoir plus, veuillez consulter le README du dépôt Github.

Seule la personne ayant fait la demande d’habilitation a accès au token, au travers du compte utilisateur API Entreprise.

• Si vous avez réalisé la demande d’habilitation, vous pouvez récupérer vos tokens ou jetons d’accès directement depuis votre compte.

• Si vous n’avez pas réalisé la demande d’habilitation mais que vous êtes la personne en charge d’intégrer l’API Entreprise, la personne ayant effectué la demande d’habilitation peut vous transmettre le token de façon sécurisée depuis son compte, en cliquant sur le bouton “Transmettre le jeton à mon équipe technique”. Vous recevrez alors, par e-mail, un lien d’une durée de 4 heures vous donnant accès au jeton.

⚠️ L’utilisation de cette fonctionnalité du compte utilisateur doit avoir pour unique objectif la transmission sécurisée de la clé aux services techniques qui intégreront l’API Entreprise. Le jeton JWT ne doit jamais être transmis par e-mail.

Utiliser l’environnement de production - Swagger

Après avoir récupéré votre jeton, vous pouvez faire un premier appel de test.

Utilisez l’environnement de production documenté (Swagger), disponible sur api.gouv.fr.
Il permet, à l’aide d’un token d’authentification valide 🔑, d’effectuer directement depuis le navigateur des tests de l’API. Les données confidentielles restent bien protégées. Vous y trouverez aussi la spécification technique téléchargeable sous format YAML afin de pouvoir accélérer le développement de vos outils d’interfaçage avec API Entreprise.

⚠️ Attention, pour rappel, vous ne devez jamais copier-coller un token dans la barre de recherche classique d’un moteur de recherche ou dans un e-mail. Pour récupérer votre jeton de façon sécurisée, consultez cette rubrique.

Éléments constitutifs de la requête HTTP d’API Entreprise

Chaque URL de requête est spécifiée dans le Swagger,

Exemple de requête :

https://entreprise.api.gouv.fr/v3/attestation_fiscales_dgfip/SirenDeL’Entreprise?token=📝&user_id=📝&context=📝&recipient=📝&object=📝

Constatez votre première trace d’appel depuis le compte utilisateur

Une fois que vous avez fait un premier appel, celui-ci est répertorié dans votre compte utilisateur, dans la page détaillée de l’habilitation concernée, au niveau du jeton. Un lien vous permet d’accéder aux statistiques.

Documentation en construction 🚧

Dès l’intégration d’API Entreprise, prenez un temps pour vous assurer d’être informé de la disponibilité de nos API :

• Ajoutez des routes de pings pour automatiser la surveillance des API par vous-même. Pour en savoir plus, consulter la rubrique “surveiller l’état des fournisseurs” ;
• abonnez-vous aux incidents et opérations de maintenance directement depuis notre page de statut.

Le service ne répond plus ? consultez cette rubrique de notre FAQ.

1. Abonnez-vous aux notifications par e-mail depuis notre page de statut.

2. Ajoutez des routes de pings pour automatiser la surveillance des API par vous-même. Plutôt que de consulter ponctuellement notre page de statuts, vous pouvez vous branchez directement à nos routes afin d’avoir un suivi encore plus précis. Pour en savoir plus, consulter la rubrique surveiller l’état des fournisseurs.

Pour comprendre comment prolonger votre jeton, consultez cette rubrique de notre FAQ.