Présentation

hotdoc est une API de traitement de documents. Vous envoyez des fichiers et des instructions textuelles (prompts), et vous récupérez en retour le texte reconnu ainsi que les réponses du modèle pour chaque fichier.

En interne, hotdoc fait trois choses : il décompresse les archives et normalise vos fichiers, les passe par l’OCR, puis envoie le texte reconnu à un modèle de langage accompagné de vos prompts. Vous ne déployez aucune infrastructure, vous ne configurez aucun pipeline OCR et vous ne payez aucune marge sur les tokens — le modèle tourne sur votre clé de fournisseur (BYOK).

Le traitement est asynchrone. Vous créez un job, récupérez son ID et interrogez son statut jusqu’à ce que le job se termine. Un même job peut contenir plusieurs fichiers, y compris des fichiers imbriqués dans des archives.

hotdoc convient bien lorsque :

• vous devez transformer un ensemble hétérogène de documents (PDF, scans, fichiers Office, archives) en texte et en extraire des données via API ;
• vous ne voulez pas faire tourner votre propre infrastructure de reconnaissance ;
• vous ne voulez pas surpayer les tokens via un intermédiaire — vous payez directement le fournisseur du modèle.

Ce que hotdoc ne fait pas : il ne convertit pas un format de fichier en un autre comme finalité (ce n’est pas un convertisseur) et il ne garantit pas une sortie conforme à un schéma (voir « Prompts et extraction de données »).

Comment fonctionne l’API en 1 minute

Une seule URL de base (https://api.hotdoc.io), un seul en-tête d’authentification, un traitement asynchrone : vous créez un job, récupérez son id et interrogez le statut jusqu’à ce que le job se termine.

Les méthodes se répartissent en trois groupes (liste complète avec les chemins dans « Référence API ») :

Le flux principal se résume à trois étapes :

POST /v1/jobs            → create a job (status JOB_STATUS_NEW)
GET  /v1/jobs/{id}       → poll the status (NEW → FILE_PROCESSING → OCR → LLM → terminal)
GET  /v1/jobs/{id}/result → fetch the result: recognized text (ocr[]) and model answers (llm[])

Il n’existe pas d’endpoint de logs distinct : les données et erreurs par étape (OCR/LLM) se trouvent dans /result ; la liste des jobs est GET /v1/jobs ; le quota restant est GET /v1/billing.

Concepts fondamentaux

Job. L’unité de traitement. Il contient un ou plusieurs fichiers sources, traverse les étapes de traitement et possède un statut. Des limites s’appliquent à la taille totale d’un job (voir « Limites »). Sur le forfait gratuit, l’usage est compté en jobs.

Source. Un fichier à traiter. Vous l’indiquez soit par une URL publique dans sourceUrls, soit en l’envoyant au préalable (voir « Envoi de fichiers »). Si une source est une archive, elle est décompressée récursivement (profondeur par défaut ≤ 3), et chaque fichier imbriqué est traité séparément.

Étapes de traitement. Chaque fichier passe par : décompression/conversion → OCR (reconnaissance de texte) → LLM (envoi du texte au modèle avec vos prompts).

Prompt. Une instruction textuelle pour le modèle. Vous transmettez un tableau prompts ; le modèle l’applique au texte reconnu de chaque fichier et renvoie une réponse textuelle.

BYOK / neural. La configuration du modèle sur la clé duquel s’exécute l’étape LLM. Elle est transmise dans le champ neural lors de la création d’un job. La clé du fournisseur n’est jamais stockée en clair — uniquement chiffrée — et elle est supprimée en même temps que le job (voir « Sécurité et données »).

BYOK / ocr. La configuration du fournisseur OCR sur lequel s’exécute l’étape de reconnaissance (OCR). Elle est transmise dans le champ ocr lors de la création d’un job et est toujours requise, au même titre que neural. Vous choisissez le fournisseur via ocr.provider (par ex. NEURAL_CLIENT_TYPE_MISTRAL), le modèle via ocr.model (par ex. mistral-ocr-latest), et fournissez votre clé dans ocr.providerKey. C’est une clé distincte de neural.apiKey : neural.apiKey est la clé du fournisseur du modèle de langage (étape LLM), tandis que ocr.providerKey est la clé du fournisseur OCR pour la reconnaissance de texte (étape OCR). Le convertisseur décide lui-même si un fichier donné nécessite l’OCR ; pour les fichiers en texte brut, la clé peut ne pas être utilisée, mais vous devez l’envoyer dans tous les cas. La clé n’est stockée que chiffrée, n’est jamais renvoyée dans les réponses et est supprimée en même temps que le job.