SDK de conversion de fichiers#

Bibliothèques client officielles pour l'API EnConvert, publiées pour dix langages : Node.js, Python, Go, Java, PHP, Ruby, C#, Rust, Kotlin et Swift. Chaque SDK couvre les deux mêmes surfaces derrière une seule clé API. La surface de conversion transforme des fichiers et des URL en d'autres formats, et la surface de web intelligence V2 perçoit, découvre, recherche, extrait, ingère et surveille des pages web en direct. Chaque client expose ces endpoints sous forme de méthodes typées, gère l'authentification, et renvoie des URL de téléchargement pré-signées.

SDK disponibles#

Les dix sont sous licence MIT.

Choisissez votre langage#

• Node.js / TypeScript : Node 18+, zéro dépendance runtime, builds ESM et CJS, définitions de types complètes.
• Python : Python 3.9+, dataclasses typées, marqueur py.typed livré pour mypy.
• Go : Go 1.21+, bibliothèque standard uniquement, aucune dépendance tierce.
• Java : Java 17+, une seule dépendance (Gson), HTTP via le HttpClient du JDK.
• PHP : PHP 8.1+, installé avec Composer, autoloadé en PSR-4.
• Ruby : Ruby 3.0+, empaqueté sous forme de gem enconvert.
• C# / .NET : .NET 8+, méthodes asynchrones de bout en bout, types référence nullables activés.
• Rust : un client bloquant construit sur reqwest, donc aucun runtime asynchrone n'est nécessaire.
• Kotlin : JDK 17+, data classes idiomatiques et kotlinx.serialization.
• Swift : macOS 12+, iOS 15+, tvOS 15+ et watchOS 8+, avec des méthodes async await.

Vous n'écrivez pas de code ? La CLI couvre la même API depuis un terminal, le serveur MCP la branche sur Claude, Cursor et Windsurf, et le nœud n8n l'intègre dans un workflow.

Pourquoi utiliser un SDK ?#

Appeler l'API REST directement fonctionne très bien, et les SDK ajoutent quatre choses par-dessus :

• Options typées. L'autocomplétion de l'éditeur couvre chaque paramètre de chaque endpoint : une faute de frappe dans un nom de champ échoue donc à la compilation ou à l'import, au lieu de revenir sous forme de 422.
• Récupération automatique après timeout. Les rendus URL vers PDF lourds et les documents volumineux dépassent parfois le timeout du reverse proxy, même quand la conversion réussit côté serveur. Les SDK génèrent un job_id côté client, l'envoient avec la requête, et se rabattent discrètement sur l'interrogation de GET /v1/convert/status/{job_id} si l'appel initial renvoie une 5xx. Vous n'écrivez aucun code supplémentaire.
• Téléchargements en flux. Pointez une méthode vers un chemin local et le SDK écrit la réponse directement sur le disque avec gestion de la contre-pression : la consommation mémoire reste plate quelle que soit la taille de la sortie.
• Erreurs cohérentes. Une petite hiérarchie d'exceptions vous laisse attraper les erreurs par classe au lieu d'analyser les codes de statut à la main.

Les deux surfaces#

Chaque SDK répartit ses méthodes de la même façon.

Chaque rendu V2 porte également un score render_quality compris entre 0.0 et 1.0. Une page bloquée, un interstitiel de défi anti-bot ou une coquille vide d'application monopage revient signalée par un score bas et des avertissements, plutôt que de passer silencieusement pour du vrai contenu : une mauvaise lecture n'entre donc jamais discrètement dans le contexte d'un agent.

Obtenir une clé API#

Chaque SDK a besoin d'une clé API privée (sk_...). Générez-en une depuis le tableau de bord et passez-la au constructeur, en la lisant depuis une variable d'environnement ou votre gestionnaire de secrets. N'écrivez jamais une clé privée en dur et ne l'embarquez jamais dans du code côté client. Le code navigateur doit utiliser une clé publique (pk_) avec un JWT, comme décrit dans Clés publiques et JWT.

Questions fréquentes#

Quels langages disposent d'un SDK officiel de conversion de fichiers ?#

Dix : Node.js et TypeScript, Python, Go, Java, PHP, Ruby, C# et .NET, Rust, Kotlin et Swift. Les dix sont officiels, sous licence MIT, et suivent la même API REST : une fonctionnalité qui arrive dans l'API est donc accessible depuis n'importe lequel d'entre eux.

Pourquoi utiliser un SDK plutôt qu'appeler directement l'API REST de conversion de fichiers ?#

Les SDK ajoutent des options typées avec autocomplétion dans l'éditeur, une récupération automatique après timeout pour les conversions longues, des téléchargements en flux directement sur le disque, et une hiérarchie d'erreurs cohérente qui vous permet d'attraper par classe d'exception sans analyser les codes de statut.

Comment le SDK gère-t-il les conversions qui dépassent le timeout du reverse proxy ?#

Le SDK génère un job_id côté client, l'envoie avec la requête, et se rabat sur l'interrogation de GET /v1/convert/status/{job_id} si la requête initiale renvoie une 5xx. Il renvoie le résultat dès que la tâche est enregistrée comme réussie, et lève une erreur si elle est enregistrée comme échouée.

Puis-je mélanger appels SDK et requêtes HTTP brutes ?#

Oui. Chaque SDK appelle les mêmes endpoints REST publics documentés sur ce site : les appels SDK et les appels HTTP écrits à la main peuvent donc partager un même projet et une même clé.

Les SDK couvrent-ils les endpoints de web intelligence V2 ?#

Oui. Les dix exposent un espace de noms V2 couvrant perceive, discover, lookup, distill, ingest et watch, en plus des méthodes de conversion de fichiers. Consultez la V1 et V2 pour savoir ce que fait chaque endpoint.

De quelle clé API un SDK a-t-il besoin ?#

D'une clé API privée (sk_...), générée depuis le tableau de bord et passée au constructeur. Lisez-la depuis une variable d'environnement plutôt que de l'écrire en dur, et ne l'intégrez jamais à du code côté client. Le code navigateur doit utiliser une clé publique avec un JWT.

Existe-t-il un SDK pour mon langage s'il n'est pas dans la liste ?#

Pas encore, et vous n'en avez pas besoin. L'API est du REST classique avec des corps JSON et multipart : n'importe quel client HTTP fonctionne. Partez de la vue d'ensemble des endpoints et du guide d'authentification.