API de parsing de CV

Ce document présente le fonctionnement de lAPI de parsing proposée par CleverConnect.

API de parsing de CV

Ce document présente le fonctionnement de l’API de parsing proposée par CleverConnect.

Cette API permet de récupérer les éléments structurés d’un CV via un simple appel HTTPS.

Racine de l’API : https://api.meteojob.com/

Appel

Type d’appel : POST

URL : /parsing/resume/{version d’API}. La version d’API courante est “v2”

Exemple

curl -XPOST \\
https://api.meteojob.com/parsing/resume/v2?auth={token}&externalRef={clientReference}&extractResumePhoto=true‘ \
-H ‘Content-Type: application/pdf’ \
-H ‘Content-Disposition: attachment; filename= »TestCVApi.pdf »‘ \
–data-binary @Fichier_cv.pdf

Paramètres de l’URL

Champs

Type

Valeur

auth

String

Jeton d’authentification, obligatoire

externalRef

String

Référence du CV (utilisée à des fins d’audit et de traçabilité des appels), optionnel

extractResumePhoto

Boolean

True pour extraire la photo, false sinon

En-têtes de la requête

Champs

Type

Valeur

Content-Type

String

Le type de CV fourni dans la requête

Pour un fichier PDF (.pdf) : application/pdf

Pour un fichier MS Word (.docx) :
application/vnd.openxmlformats- officedocument.wordprocessingml.document…

Content-Disposition

String

Une valeur de la forme « attachment; filename=nomDeFichier », où le nom de fichier est échappé de façon conforme aux normes HTTP et MIME.

Le nom de fichier doit contenir une extension compatible avec le Content-Type

Corps de la requête

Le corps de la requête est le contenu du document à interpréter. Les documents de type .pdf, .txt, .odt, .rtf, .doc, .docx sont acceptés.

Le système accepte aussi les requêtes multipart/form-data, auquel cas :

– Le header Content-Type doit avoir pour valeur « multipart/form-data »
– Un seul fichier est traité par appel (le premier rencontré)
– Les headers Content-Type / Content-Disposition de chaque partie doivent être valorisés conformément aux recommandations ci-dessus.

Code d’état de la réponse

 

Code retour

Description

20x

OK

40x

Erreur de requête.
400
: mauvais format de requête (absence de fichier, absence de header, impossibilité de déterminer le format du fichier)
402 : dépassement du nombre de parsings autorisés
403 : erreur d’authentification (liée au token)

50x

Erreur interne.
– Dépassement du temps de traitement maximal autorisé
– Corruption du fichier non détectable initialement (fichiers docx)
– Autres erreurs internes au programme

Corps de la réponse

Le format de retour est toujours structuré de la même façon.

En cas d’échec, un message JSON est retourné contenant le code d’erreur HTTP et une codification de la cause de l’erreur.
Cette codification est de la forme {source}-{cause}, et couvre aussi bien les éventuelles erreurs internes que les erreurs provenant d’une mauvaise requête.

Les sources possibles sont :

– REQ : erreur liée à la donnée fournie par l’appelant
– SERPROD : erreur liée au contrôle des droits d’accès
– MED_USER : erreur liée à la conversion de format (exemple : fichier word ou image corrompue)
– autres valeurs : usage interne.

Les causes possibles sont :

– TO : temps de traitement dépassé
– FMT : mauvais format de données
– FMT_MIME : structure MIME invalide dans la requête
– FMT_FEW : format de donnée fourni non détectable
– INVALID ou FORBIDDEN : droits épuisés pour accès à l’API
– GEN : cause non précisée à l’appelant


Principes généraux

Le format HR-JSON prévoir de nombreux champs, dont l’utilisation exacte est à l’appréciation de l’applicatif. Voici donc une présentation des principes retenus.

 

Respect du texte original

A chaque fois que possible, la donnée textuelle originale est retournée « à côté » de la donnée interprétée et structurée. Cela permet à l’appelant de se référer à du texte en langage naturel pour chaque structure.
Dans le cas des dates, le format HR-JSON prévoit l’utilisation de ISO 8601. L’API respecte ce format et se tronquera toujours, autant que possible, à la précision fournie par le candidat (année seule par exemple).

 

Types à identifiant

Pour certaines de ces données interprétées, le format HR-JSON utilise des types dérivants de IdentifierType.

Quand l’id d’un IdentifierType est instancié dans l’API, il représente une « projection » d’un élément en texte naturel (un diplôme, un permis, un métier, …) sur un référentiel fixe et pérenne de données maintenu par CleverConnect.

 

  • id représente l’entité (par exemple un niveau de diplôme)
  • value représente l’identifiant (numérique ou chaîne de caractère, selon les cas)
  • shemeId représente le nom du référentiel
  • description représente le libellé

Le couple (value, schemeID) est unique, stable dans le temps, et permet de se référer à cette entité.
Il est à noter que le processus de reconnaissance des valeurs textuelles peut échouer, auquel cas, le champ value n’est pas renseigné.
Dans les types JSON qui l’autorisent, au même niveau que le champ id, se situe un champ name, qui contient le texte en langage naturel ayant donné lieu à la création de l’entité, et le champ type, qui indique le rôle que joue ce texte (par exemple, dans l’expression « BAC STT », « STT » est la spécialisation du diplôme.

Liste des schemeID

Scheme ID

Description

DEGREE_LEVEL

Niveau de diplôme (au sens légal), de I à V

DEGREE

Le référentiel de diplômes de CleverConnect (par exemple, les niveaux génériques BAC+x)

JOB

Le référentiel de métiers

Permis de conduire

Compétence (hard skill)

Langues

Type de contrat (CDI, CDD)

Temps plein ou partiel

 

Exemple de réponse

Téléchargez cet exemple pour mieux comprendre le fonctionnement de notre API !

Structure du fichier JSON

Comprenez la structure de notre fichier JSON en téléchargeant la documentation.

logo CleverConnect
Retrouvez-nous

CleverConnect
14 Rue Gaillon
75002 Paris

Contact :

+33 1 56 92 31 00

E-mail