API REST
Votre propre code, lisant HumanR et l'alimentant — via un token, pas un mot de passe de base de données
Une API REST versionnée que vos systèmes appellent avec un token porteur : lire les employés, les jours de présence, les demandes de congé, les cycles d'examen et les objectifs, et les listes de référence — et poster les pointages de présence à partir d'un système horaire qui ne parle que HTTP. Les tokens sont affichés une fois et stockés hachés, et un token ne peut jamais porter une permission que l'administrateur qui l'a émis ne tenait pas.
Voir en direct — démo en quelques minutes →Cela vous semble familier ?
La seule façon de sortir les données est que quelqu'un exporte un fichier et l'envoie par e-mail
Un système horaire ou un kiosque peut produire des pointages, mais il n'y a nulle part où les envoyer
L'alternative sur la table est de remettre à un intégrateur un mot de passe de base de données
Le credential dans ce script a été là depuis deux ans et personne ne sait qui l'a émis
Capacités
Ce que vous obtenez
10 capacités
Un token qui ne peut pas dépasser la personne qui l'a émis
Les scopes sont choisis à partir de ce que l'administrateur émetteur détient déjà, de sorte qu'un token est une copie resserrée de la portée existante d'un opérateur et n'est jamais un moyen de la contourner. Accordez un token en lecture-présence uniquement et c'est précisément ce qu'il peut faire — les mêmes vérifications de permission que l'app web s'exécute s'appliquent inchangées derrière l'endpoint.
Affiché une fois, stocké haché
Le token brut s'affiche à l'écran exactement une fois, à l'émission. Seul son hash est conservé, de sorte que personne — y compris nous — ne puisse lire un token du base de données. Un token perdu est révoké et réémis plutôt que récupéré, qui est le comportement correct et la raison pour laquelle c'est utile à dire à voix haute.
Émis et révoqué au dossier
Chaque émission et révocation est écrite à la piste d'audit par le préfixe court du token, jamais son hash, de sorte qu'un an plus tard vous puissiez toujours répondre qui a créé les credentials maintenant assis dans le script de quelqu'un — sans que le journal lui-même devienne un endroit où les credentials fuient.
Lire les employés, présence, congés, performance et données de référence
Les listes d'employés et les dossiers uniques, les jours de présence avec premier entrée, dernière sortie et comptages de pointages, les demandes de congé, les cycles d'examen avec les examens et objectifs en dessous, et les listes de référence derrière chaque déroulement — entreprises, départements, désignations et sites de travail. Paginés, filtrés et plafonnés de sorte qu'aucune demande ne puisse tirer la table entière.
Pousser les pointages de présence
Un lot de pointages postés à partir de n'importe quel système qui peut faire une demande HTTP. Idempotent sur l'employé et l'horodatage, de sorte que l'envoi après un timeout ne stocke rien deux fois, et un lot mixant les bonnes et les mauvaises lignes atterrit les bonnes et rend le reste pour correction — pas d'échecs tout ou rien sur une synchronisation quotidienne.
Les limites de l'entreprise qu'un token ne peut pas contester
Portez un token à une entreprise et chaque requête est filtrée avant que n'importe quel paramètre de demande ne soit lu. Un appelant demandant les lignes d'une autre entreprise reçoit les lignes de sa propre entreprise, pas une erreur et pas les données de quelqu'un d'autre.
Les champs sensibles restent derrière leurs propres permissions
Le salaire et les identifiants personnels sont masqués dans les réponses API sauf si le token porte le scope sensitive-data, exactement comme ils se trouvent dans l'interface. Il n'y a pas de trappe où l'API retourne plus que le même utilisateur verrait à l'écran.
Documenté et explorable
Un document OpenAPI généré et un explorateur interactif vivent derrière la même connexion que le reste de l'application, de sorte qu'un intégrateur puisse lire chaque endpoint, paramètre et forme de réponse et essayer un appel contre vos propres données plutôt que de travailler à partir d'un PDF.
Limité de débit par token
Chaque token reçoit son propre budget par minute plutôt que de partager un pool global, de sorte que la boucle d'ingestion d'un intégrateur ne peut pas affamer celle d'un autre, et le plafond est une valeur de configuration que votre installation peut régler.
Absent sauf si vous l'aviez demandé
L'API est un commutateur par locataire. Avec lui désactivé, chaque route — les endpoints, la documentation et l'écran de token — répondent 404 plutôt que 403, de sorte qu'une instance qui ne l'a pas activée ressemble à un scanner exactement comme celle où la fonctionnalité n'existe pas.
Tout ce qui peut faire une demande HTTP
Il n'y a pas de connecteur à construire et pas de SDK à adopter : l'API est JSON simple sur HTTPS avec un token porteur, que chaque langue, chaque plate-forme d'automatisation et la plupart des systèmes temps-et-accès peuvent déjà parler.
Directement du produit
Vrais écrans de l'entreprise de démonstration — le même système que votre identifiant ouvre.
Fonctionne mieux avec
Webhooks et diffusion d'événements
Quand la paie se finalise ou qu'un permis est sur le point d'expirer, vos autres systèmes l'entendent — automatiquement
Explorer →Biométrie et heures supplémentaires
Les pointages s'écoulent depuis vos appareils — les relevés de présence se construisent eux-mêmes
Explorer →Recherche, filtrage et export
Vos réflexes Excel, améliorés — filtrez n'importe quelle liste, façonnez-la, emportez-la avec vous
Explorer →Questions
Qu'est-ce que l'API peut écrire ?
Les pointages de présence, et uniquement les pointages de présence. Tout le reste est en lecture seule aujourd'hui : les employés, les jours de présence, les demandes de congé, les cycles de performance, les examens et objectifs, et les listes de référence tout vient, mais rien ne rentre. C'est un point d'arrêt délibéré plutôt qu'une oubli — l'ingestion de pointages est l'écriture qui débloque les vraies intégrations, et créer des employés ou approuver les congés via une API a besoin de la même sémantique d'approbation et d'audit que l'interface applique, que nous préférerions construire correctement plutôt que vite.
En quoi cela diffère-t-il des webhooks ?
Directions opposées, et la plupart des intégrations veulent les deux. Les webhooks poussent HumanR vers vous le moment où quelque chose se produit — une série de paie se finalise, un permis est des semaines de l'expiration — sans polling. L'API est votre code tirant selon votre propre calendrier, ou poussant des pointages. Une configuration typique s'abonne aux événements qui me concernent et appelle l'API pour récupérer le détail derrière eux.
Est-il sûr de donner un token à un vendeur ?
Plus sûr que l'alternative généralement proposée, qui est une connexion à la base de données. Un token porte uniquement les scopes que vous cochez, peut être épinglé à une seule entreprise, expire à une date que vous définissez, est limité en débit sur son propre, et est révocable en un clic sans déranger personne d'autre. Et parce qu'il ne peut jamais dépasser les permissions de l'administrateur qui l'a émis, le rayon de blast d'un token divulgué est borné par une personne que vous pouvez nommer.
Explorez avec vos données réelles
Demandez une démonstration et nous vous enverrons une connexion personnelle à une entreprise de démonstration entièrement chargée — explorez les vrais écrans avec des données réalistes en quelques minutes.
Pas de carte bancaire. Aucun appel de vente requis. Une vraie connexion, envoyée par email.