API d’intégration

Authentification

En-tête Authorization: Bearer jh_live_…. La clé se crée dans le dossier (administrateur) et n’est affichée qu’une fois. JURHUMA conserve un hash, jamais le secret.

Le rôle de la clé est celui d’un membre : Administrateur, RH, Pointeuse, Lecture seule. Arrivées, départs, horaires, absences. Jamais les salaires ni les congés payés.

Exemple

curl -sS https://jurhuma.mg/api/v1/me \
  -H "Authorization: Bearer jh_live_…"

curl -sS https://jurhuma.mg/api/v1/employees?active=1 \
  -H "Authorization: Bearer jh_live_…"

curl -sS -X PUT https://jurhuma.mg/api/v1/attendance \
  -H "Authorization: Bearer jh_live_…" \
  -H "Content-Type: application/json" \
  -d '{"employeeId":"…","date":"2026-09-16","arrival":"08:00","departure":"17:00"}'

Ressources

• GET/api/v1Découverte de l’API
• GET/api/v1/openapi.jsonSchéma OpenAPI
• GET/api/v1/meIdentité de la clé
• GET/api/v1/companyFiche entreprise
• GET/api/v1/employeesListe des salariés
• POST/api/v1/employeesCréer un salarié
• GET/api/v1/employees/:idFiche salarié
• PATCH/api/v1/employees/:idModifier un salarié
• GET/api/v1/attendancePointage
• PUT/api/v1/attendanceSaisir un jour
• GET/api/v1/employees/:id/attendancePointage d’un salarié
• GET/api/v1/payslipsBulletins émis
• GET/api/v1/payslips/:idUn bulletin émis
• GET/api/v1/leaveCongés posés
• POST/api/v1/leavePoser un congé

Catalogue machine : /api/v1 · OpenAPI. 2 lecture de bulletins — uniquement les documents déjà émis, jamais un recalcul.

Sécurité

Audit interne de l’API partenaire : jeton Bearer, pas de cookie de session, rôles du dossier, plafond de corps, journal d’accès. Les contrôles ci-dessous sont ceux du serveur, pas une checklist marketing.

• Authentification par jeton, pas par cookieen place

  Authorization: Bearer jh_live_… ou X-Api-Key. Le cookie de session du compte n’ouvre pas l’API. Le secret n’est stocké qu’en SHA-256.

• Comparaison en temps constanten place

  Le hash du jeton est comparé octet par octet (XOR) sur toute la liste des préfixes, y compris en cas d’absence, pour ne pas fonder un oracle de timing.

• Mêmes rôles que le dossieren place

  Planning et lecture ne reçoivent ni salaires, ni bulletins, ni identifiants d’entreprise. Un mois déjà payé ne se réécrit pas.

• Limitation de débiten place

  180 requêtes / minute par adresse, 120 / minute par clé. Au-delà : HTTP 429.

• Plafond de corpsen place

  JSON limité à 65536 octets. Un corps plus gros est rejeté avant parsing.

• CORS sans credentialsen place

  Origine * uniquement parce que l’API n’utilise pas le cookie de session. Pas de Access-Control-Allow-Credentials.

• Essai et licenceen place

  Le dossier spécimen n’émet pas de clé. Une licence suspendue reste en lecture seule.

• Journal d’accèsen place

  Chaque appel authentifié est horodaté (clé, chemin, statut, IP). Conservation 12 mois.

• En-têtes de réponseen place

  nosniff, DENY (frame), no-store, referrer no-referrer. Pas de cache d’une fiche salarié.

• Erreurs internes opaquesen place

  Un incident serveur renvoie { error: { code: "internal" } }, jamais la pile ni le message d’exception.

Limites

• Dossier d’essai (spécimen) : pas de clé. Abonnement requis.
• Essai payant 14 jours : cinq salariés, un mois de paie émis, documents marqués ESSAI.
• Un rôle planning ne reçoit jamais les salaires ni les bulletins.
• Un mois déjà payé ne se réécrit pas, y compris par l’API.
• Les identifiants d’entreprise (NIF, CNaPS…) ne sortent que pour une clé RH ou administrateur.