Comment collecter des offres d'emploi publiques Naukri via une API

1. Fixez une recherche et un plafond de lignes

Notez les lignes voulues avant de commencer. Choisissez un métier. Choisissez une ville indienne, ou laissez la ville vide. Choisissez l'âge autorisé de la publication source. Choisissez un petit nombre maximal de lignes enregistrées.

L'Actor public actuel accepte cette entrée :

• `searchTerm` prend un mot-clé sur chaque ligne.
• `location` est facultatif.
• `maxItems` est le plafond de lignes. Il limite les lignes enregistrées pour toute l'exécution. Le plafond n'est pas séparé pour chaque ligne de mot-clé. Si vous l'omettez, le plafond numérique disparaît. Envoyez toujours un nombre pour cette méthode.
• `postedWithinDays` est du texte. Utilisez "0", "1", "3", "7", "15" ou "30". Le texte "0" signifie n'importe quelle date de publication.
• `experienceYears` est facultatif. C'est un nombre entier de 0 à 30. Fresher signifie peu ou pas d'expérience professionnelle antérieure dans ce réglage de recherche. La valeur 0 demande le réglage de recherche Fresher. Cette méthode ne juge pas l'adéquation au poste.
• `sortBy` vaut `relevance` ou `date`.
• `excludeCompanies` est facultatif. L'exemple ci-dessous ne l'utilise pas.
• `searchDepth` vaut `standard`, `extended` ou `deep`. `standard` est le contrôle initial, avec une portée de recherche limitée. Il lit moins de pages source que les deux autres. Cette méthode n'a pas besoin d'une recherche plus profonde.

La Task publique actuelle enregistre `searchTerm` "software engineer", `postedWithinDays` "7", `sortBy` "date" et `searchDepth` "standard". Mettez votre métier dans `searchTerm`. Mettez votre ville dans `location` si vous voulez une seule ville. Fixez votre propre `maxItems`.

Un contrôle vérifié a utilisé d'autres valeurs. Il a utilisé un mot-clé, "software engineer". Il n'a envoyé aucun lieu. Il a utilisé `postedWithinDays` "0", `maxItems` 2, `sortBy` "relevance" et `searchDepth` "standard". L'exécution a enregistré deux ID d'emploi Naukri distincts. Chaque ligne avait un titre, un nom d'entreprise et un lieu. Chaque ligne avait un `jobUrl` Naukri direct. Chaque `sourceUrl` correspondait à la requête demandée. `source` était naukri.com. Chaque ligne avait `observedAt`. Les deux lignes incluaient `descriptionText`. Les deux lignes incluaient `experienceRaw`. Les deux plages numériques étaient 0-5 et 0-2. Ces zéros sont des années minimales observées. Ce ne sont pas des champs vides. Le contrôle n'a pas envoyé `experienceYears`. Il ne prouve pas qu'un filtre Fresher a été appliqué.

L'exécution vérifiée s'est terminée avec succès. Son enregistrement OUTPUT montrait ces valeurs connues. `rowsSaved` était 2. `requestedMaxItems` était 2. `pagesRequested` était 1. Le reçu indiquait 20 annonces candidates vues. `failedRequests` était 0. `blockedRequests` était 0. `stopReason` était `max_items_reached`. L'exécution a atteint le plafond. Deux lignes enregistrées ne sont pas tous les emplois correspondants. Le contrôle n'a pas indiqué `searchesQueued`, `searchesFinished` ni `sourceStates`. Ces trois valeurs sont inconnues. Inconnu n'est pas la même chose que 0.

Une ligne enregistrée peut inclure les champs ci-dessous.

• `schemaVersion`
• `jobId`
• `title`
• `companyName`
• `location`
• `experienceRaw`
• `experienceMinYears`
• `experienceMaxYears`
• `skills`
• `descriptionText`
• `postedAt`
• `postedAtRaw`
• `jobUrl`
• `searchTerm`
• `searchLocation`
• `sourceUrl`
• `pageNumber`
• `rankOnPage`
• `status`
• `statusReason`
• `source`
• `observedAt`

Une valeur facultative peut être absente. L'absence est inconnue. Ce n'est pas un zéro. `descriptionText` peut être présent et manquer encore une partie du texte de l'employeur. Il peut aussi manquer une exigence. `postedAt` et les champs d'expérience sont ce que la source a montré. Ils ne sont pas une promesse que l'employeur embauchera. `observedAt` est le moment où l'Actor a vu la ligne. Ce n'est pas le moment où Naukri a publié l'annonce pour la première fois. Gardez ces deux moments séparés.

`searchTerm`, `searchLocation` et `observedAt` appartiennent à la ligne source brute. Si vous ajoutez plus tard votre propre colonne de requête, vous avez créé cette colonne. Ce n'est pas un champ source nommé query.

2. Démarrez l'exécution et conservez l'ID d'exécution

Utilisez votre propre compte Apify. Gardez le jeton à l'endroit sûr que votre projet utilise déjà pour les secrets. Un jeton est un secret qui prouve que l'appel appartient à votre compte. Gardez un vrai jeton hors des articles. Gardez-le hors du code du navigateur. Gardez-le hors des journaux. Gardez-le hors d'une image d'URL. Cette lecture publique n'a pas besoin d'une connexion Naukri.

L'appel de démarrage renvoie des informations sur l'exécution. Il ne renvoie pas de lignes d'emploi. Une exécution est un démarrage de l'Actor. Envoyez l'entrée en JSON. JSON est un format texte pour des données structurées. Incluez l'en-tête `Content-Type: application/json`. Envoyez le jeton dans l'en-tête `Authorization`. Écrivez `Bearer`, une espace, puis le jeton. Le corps ci-dessous est une entrée pédagogique originale. Ce n'est pas un résultat en direct.

POST https://api.apify.com/v2/acts/chronometrica~naukri-jobs-scraper/runs
Authorization: Bearer <APIFY_TOKEN>
Content-Type: application/json

{
  "searchTerm": "data analyst",
  "location": "Bengaluru",
  "maxItems": 2,
  "postedWithinDays": "7",
  "sortBy": "date",
  "searchDepth": "standard"
}

Ce corps demande le métier data analyst. Il limite le lieu à Bengaluru. Il enregistre au plus 2 lignes. Il demande les publications des 7 derniers jours. Il trie par date. Il utilise la profondeur standard. La documentation de démarrage d'exécution décrit ce point d'accès. La même API permet de fixer un délai d'expiration et un plafond de facturation. Un plafond de facturation arrête l'exécution à une limite de coût que vous choisissez. Fixez les deux limites pour une première exécution. Cet article ne donne aucun prix.

Dans la réponse, enregistrez `data.id`. C'est l'ID d'exécution. Enregistrez aussi l'entrée et les options que le service a stockées. L'ID d'exécution, l'ID de dataset et l'ID de store sont trois valeurs différentes. Gardez-les distinctes.

3. Attendez un état terminé

Lisez l'exécution avec le même en-tête privé. Attendez un court moment entre les lectures. Arrêtez-vous quand le statut est terminal. Un statut terminal est un statut terminé. Les valeurs terminées sont `SUCCEEDED`, `FAILED`, `TIMED-OUT` et `ABORTED`.

GET https://api.apify.com/v2/actor-runs/<RUN_ID>
Authorization: Bearer <APIFY_TOKEN>

Enregistrez `status`, `buildId`, `startedAt`, `finishedAt`, `defaultDatasetId` et `defaultKeyValueStoreId`. `SUCCEEDED` signifie que l'Actor a fini. Cela ne signifie pas que la source a été couverte en entier. `FAILED`, `TIMED-OUT` et `ABORTED` demandent un examen avant de faire confiance aux lignes. La documentation du statut d'exécution décrit cette lecture.

4. Lisez le reçu OUTPUT

OUTPUT est l'enregistrement de synthèse de l'Actor. Lisez-le dans le magasin clé-valeur. Un magasin clé-valeur contient des enregistrements nommés pour l'exécution. Utilisez `defaultKeyValueStoreId` comme ID du magasin.

GET https://api.apify.com/v2/key-value-stores/<STORE_ID>/records/OUTPUT
Authorization: Bearer <APIFY_TOKEN>

Lisez ces champs :

• `rowsSaved` est le nombre de lignes stockées.
• `requestedMaxItems` est le plafond que vous avez demandé.
• `searchesQueued` est le travail de recherche mis en file.
• `searchesFinished` est le travail de recherche qui s'est terminé.
• `pagesRequested` est le nombre de pages source demandées. Une page source est une page de résultats Naukri. Ce n'est pas une lecture du dataset enregistré.
• `blockedRequests` est le nombre de requêtes source bloquées.
• `failedRequests` est le nombre de requêtes source en échec.
• `sourceStates` indique comment la source s'est terminée.
• `stopReason` indique pourquoi l'Actor s'est arrêté.

Si `rowsSaved` est égal à `requestedMaxItems` et si `stopReason` vaut `max_items_reached`, le plafond a arrêté l'exécution. Les lignes peuvent encore servir. Elles ne sont pas la recherche complète. Un 0 compté signifie que l'Actor n'a signalé aucun élément. Un champ absent est inconnu. Ne changez pas inconnu en 0.

Utilisez `sourceStates` avant d'expliquer un fichier vide. Un résultat vide peut signifier que la source n'a renvoyé aucune ligne. Il peut aussi signifier que la source n'a pas été atteinte. Ces deux issues sont différentes. Si `failedRequests` ou `blockedRequests` est supérieur à 0, ne traitez pas la ville comme vide. Si `sourceStates` est absent, l'issue de la source est inconnue. Conservez le reçu dans les deux cas.

5. Lisez le dataset après la fin de l'exécution

Un dataset est l'ensemble enregistré des éléments de ligne. Lisez-le après que l'exécution est terminale. Un dataset qui grandit encore n'est pas stable. Terminez d'abord l'exécution. Si vous avez besoin de lignes avant la fin, concevez ce cas exprès. Ne traitez pas une page du milieu comme l'ensemble final.

GET https://api.apify.com/v2/datasets/<DATASET_ID>/items?format=json&offset=0&limit=2
Authorization: Bearer <APIFY_TOKEN>

La réponse est un tableau JSON. `offset` est le nombre de lignes enregistrées à sauter. `limit` est le nombre de lignes à renvoyer dans cette lecture. Cette lecture est une page de dataset. Ce n'est pas une page source Naukri. La documentation des éléments de dataset décrit cet appel. Comptez les lignes du tableau. Ajoutez ce nombre à `offset`. Lisez de nouveau. Conservez un petit reçu pour chaque lecture. Le reçu doit contenir offset, limit, le nombre renvoyé et toute erreur de lecture.

Pour un dataset terminé de deux lignes, la première lecture peut renvoyer deux lignes. La lecture suivante utilise offset 2 et limit 2. Elle peut renvoyer un tableau vide. Le tableau vide a un nombre renvoyé de 0. Ce 0 signifie que cette page n'avait plus de lignes. Il ne signifie pas que les lignes précédentes ont disparu. Les lignes lues sont 2. Si `rowsSaved` est 2, ces nombres correspondent.

Si une lecture de dataset échoue, conservez cet échec dans le reçu. Ne remplacez pas une lecture en échec par un tableau vide. Les lignes non lues restent inconnues.

6. Enregistrez l'identité avant de filtrer

Stockez la ligne brute. Stockez `jobId` comme texte. Conservez les zéros de tête. Un programme qui stocke l'ID comme un nombre peut supprimer ces zéros. Ajoutez le préfixe source `naukri:` à l'ID d'emploi. Ce préfixe est l'espace de noms. Un espace de noms montre quel site a créé l'ID. Un autre site d'emploi peut utiliser les mêmes chiffres pour un emploi différent. Son espace de noms reste séparé.

Stockez aussi `jobUrl`, `sourceUrl`, le `searchTerm` brut, le `searchLocation` brut, `observedAt` et l'ID d'exécution. Vérifiez que l'identité est présente. Vérifiez les types attendus. Si `jobId` est absent, la ligne reste non résolue. Non résolu signifie que vous ne pouvez pas encore lier la ligne à un emploi source. Ne créez pas de clé source pour elle.

Une observation est une vue enregistrée d'une ligne source. La même annonce lors d'une exécution ultérieure est une nouvelle observation d'un emploi source connu. Ce n'est pas automatiquement un nouvel emploi ouvert. Gardez les lignes en double visibles. Gardez visible un conflit entre deux lignes pour une même identité. Appliquez ensuite les règles de votre projet. Conservez les lignes en échec dans le reçu quand vous sélectionnez les lignes utiles.

Le sens du salaire est hors de cette méthode. Les règles d'adéquation au poste sont hors de cette méthode. Cette méthode ne dépose pas de candidatures. Une planification ultérieure est un nouveau choix. Cet article ne démarre pas une collecte répétée.

7. Constituez un reçu terminé

L'histoire de cette section est une fiction originale. Ce n'est pas une sortie de test en direct. Ce n'est pas un résultat de produit. Les ID, les URL et les heures sont inventés pour l'enseignement. N'accédez pas à ces URL fictives et n'envoyez aucune requête réseau vers elles. Ne traitez pas les lignes comme de vraies lignes Naukri.

L'exécution fictive R1 utilise le corps pédagogique de la section de démarrage. La requête de l'histoire est un POST vers `https://api.apify.com/v2/acts/chronometrica~naukri-jobs-scraper/runs` avec `Content-Type: application/json`. La réponse de démarrage de l'histoire inclut `data.id` "R1". Elle n'inclut aucune ligne d'emploi.

R1 se termine plus tard avec le statut `SUCCEEDED`. L'ID de dataset de l'histoire est D1. L'ID de store de l'histoire est K1. L'enregistrement d'exécution conservé dans l'histoire ressemble à ceci :

{
  "data": {
    "id": "R1",
    "status": "SUCCEEDED",
    "buildId": "fiction-build",
    "startedAt": "2026-04-01T09:00:00Z",
    "finishedAt": "2026-04-01T09:05:00Z",
    "defaultDatasetId": "D1",
    "defaultKeyValueStoreId": "K1"
  }
}

L'enregistrement OUTPUT de l'histoire est :

{
  "rowsSaved": 2,
  "requestedMaxItems": 2,
  "failedRequests": 0,
  "stopReason": "max_items_reached"
}

Dans cette histoire, `blockedRequests`, `searchesQueued`, `searchesFinished`, `pagesRequested` et `sourceStates` ne sont pas donnés sur cet enregistrement OUTPUT. Laissez-les inconnus. N'écrivez pas 0 pour eux. `failedRequests` est 0 parce que l'histoire dit qu'il n'y a eu aucune requête en échec. Ce 0 est connu.

La première lecture du dataset utilise offset 0 et limit 2. Elle renvoie ce tableau :

[
  {
    "jobId": "000101",
    "jobUrl": "https://www.naukri.com/example-fiction/000101",
    "sourceUrl": "https://www.naukri.com/example-fiction/search",
    "searchTerm": "data analyst",
    "searchLocation": "Bengaluru",
    "source": "naukri.com",
    "observedAt": "2026-04-01T09:04:00Z"
  },
  {
    "jobId": "000102",
    "jobUrl": "https://www.naukri.com/example-fiction/000102",
    "sourceUrl": "https://www.naukri.com/example-fiction/search",
    "searchTerm": "data analyst",
    "searchLocation": "Bengaluru",
    "source": "naukri.com",
    "observedAt": "2026-04-01T09:04:00Z"
  }
]

Le nombre renvoyé est 2. Ces lignes de l'histoire n'incluent pas `postedAt`. L'heure de publication est inconnue. Elle n'est pas 0. La lecture suivante utilise offset 2 et limit 2. Elle renvoie :

[]

Le nombre renvoyé est 0. Les lignes lues sont 2. `rowsSaved` est 2. Les nombres correspondent : 2 est égal à 2. Les ID source connus sont `naukri:000101` et `naukri:000102`. Cela fait deux ID connus. Les zéros de tête restent dans le texte. Les deux lignes conservent l'URL source de l'histoire, les champs de requête bruts et `observedAt`. Le plafond signifie deux annonces observées. Il ne signifie pas que Bengaluru n'a que deux emplois ouverts.

Une partie ultérieure de la même fiction est l'exécution R2. L'histoire dit que R2 renvoie de nouveau `000102`, et aussi `000103`. Elle ne donne pas d'enregistrement OUTPUT séparé. N'inventez pas `stopReason` ni des nombres de requêtes pour R2. Ses deux lignes d'histoire sont :

[
  {
    "jobId": "000102",
    "jobUrl": "https://www.naukri.com/example-fiction/000102",
    "sourceUrl": "https://www.naukri.com/example-fiction/search",
    "searchTerm": "data analyst",
    "searchLocation": "Bengaluru",
    "source": "naukri.com",
    "observedAt": "2026-04-08T09:04:00Z"
  },
  {
    "jobId": "000103",
    "jobUrl": "https://www.naukri.com/example-fiction/000103",
    "sourceUrl": "https://www.naukri.com/example-fiction/search",
    "searchTerm": "data analyst",
    "searchLocation": "Bengaluru",
    "source": "naukri.com",
    "observedAt": "2026-04-08T09:04:00Z"
  }
]

Stockez les deux lignes R2 comme de nouvelles observations. Seul `naukri:000103` est un nouvel ID source connu. `naukri:000102` est déjà connu.

L'arithmétique utilise des comptes simples :

• Observations R1 = 2.
• Observations R2 = 2.
• Toutes les observations = 2 + 2 = 4.
• ID connus après R1 = 2.
• Nouvel ID connu sur R2 = 1.
• ID connu répété sur R2 = 1.
• ID connus après les deux exécutions = 2 + 1 = 3.
• ID non résolus dans ces quatre lignes = 0, parce que chaque ligne de l'histoire a un `jobId`.

Quatre observations ne sont pas quatre emplois. Trois ID source connus ne sont pas trois emplois d'employeur. L'histoire n'a pas de correspondance séparée entre employeurs. Elle ne prouve pas trois postes ouverts.

Un contrôle fictif supplémentaire ne fait pas partie de ces quatre lignes. Si un téléchargement répète `000102` sur la même page, enregistrez le doublon. Ne créez pas une seconde identité. L'ID connu reste `naukri:000102`. Si une autre ligne de l'histoire a un titre mais pas de `jobId`, ajoutez 1 aux non résolus. Ne créez pas une clé telle que `naukri:unknown`.

Donnez à votre projet les lignes brutes, les ID d'exécution et ce reçu. Ajoutez une courte note : les lignes viennent de pages Naukri publiques par cet Actor. Ajoutez l'heure dans `observedAt`. Le projet peut alors utiliser l'échantillon. Le plafond n'est pas un marché complet.