Paramètres du compte et comportement de l'API
Certains comportements de votre compte sont configurés une fois, sur la page des paramètres du profil de l'application web — pas via cette API. Cette page explique, pour chacun de ces paramètres, exactement comment il se manifeste dans la v1 : si l'API le suit inconditionnellement, ou si elle vous permet de le remplacer par requête. Ceci n'est volontairement pas dispersé dans la documentation de chaque endpoint — c'est rassemblé ici car le comportement transversal est facile à manquer si vous ne lisez qu'une page de référence d'un seul endpoint à la fois.
Règle générale
La v1 lit directement la configuration actuelle de votre compte et l'applique — il n'existe pas de système de configuration séparé au niveau de l'API, et (à une exception délibérée près, ci-dessous) aucun moyen de remplacer un paramètre du compte pour une seule requête. C'est intentionnel : maintenir deux endroits indépendants pour configurer le même comportement (l'application web et une configuration API parallèle) finirait inévitablement par diverger, et l'objectif est que le même compte se comporte de la même manière quelle que soit la surface — application web, cette API, ou le module complémentaire Google Sheets — qui a lancé le traitement.
Paramètres et leur comportement dans l'API
| Paramètre | Comportement dans l'application web | Comportement dans l'API v1 | Peut être remplacé par requête ? |
|---|---|---|---|
Annotation automatique bboxauto_annotate_bbox | Un basculement au niveau du compte. Lorsqu'il est activé, chaque extraction terminée déclenche automatiquement un passage d'annotation bbox payant. | Suivi exactement — les lots créés et traités via v1 obéissent à ce basculement sans exception. S'il est activé, vous pouvez être facturé pour l'annotation bbox même si vous n'appelez jamais POST /documents/{document_id}/bbox vous-même. | Non. Aucun moyen au niveau de la requête de l'ignorer ou de le forcer. |
Qualité de traitementthinking_type | Un paramètre au niveau du compte qui choisit un niveau de vitesse/qualité pour le traitement. | La seule exception à la règle ci-dessus. Lorsque vous omettez quality sur POST /batches/{batch_name}/process, il revient au paramètre actuel de votre compte — même comportement que l'application web. Mais vous pouvez aussi passer quality: "fast" ou quality: "high" sur cette requête pour le remplacer pour cet appel uniquement. | Oui — le seul paramètre de cette page que vous pouvez remplacer par requête. |
Conservation des donnéesauto_delete / auto_delete_after | Un paramètre au niveau du compte pour supprimer automatiquement les images originales N jours après le traitement. | Suivi exactement — les documents créés via v1 sont soumis à la même politique de conservation que tout ce qui est téléchargé via l'application web. | Non. |
| Mode de traitement (interne rec_mode, exposé comme mode) | L'application web prend actuellement en charge l'extraction sous forme de tableau et la conversion complète du document en Word. | v1 ne prend actuellement en charge que mode=table (extraction de champs structurés). La conversion complète du document est prévue mais pas encore disponible via l'API. | Pas encore applicable — il n'y a qu'une seule valeur parmi laquelle choisir. Lorsque d'autres modes seront disponibles, ce sera un ajout pur, pas un changement de comportement de la valeur existante. |
Pourquoi ne pas simplement ajouter des surcharges au niveau de la requête ?
L'annotation automatique bbox et la politique de conservation sont traitées comme une gouvernance au niveau du compte, et non comme des préférences par appel — ce sont des interrupteurs du type « activé pour tout, ou désactivé pour tout » où le fait de laisser un seul appel API s'écarter silencieusement de la configuration permanente du compte créerait exactement le problème de dérive entre deux sources de configuration que cette conception évite. quality est différent : le niveau de vitesse/qualité approprié peut varier d'un appel à l'autre (ce lot doit être traité rapidement, celui-ci nécessite une précision maximale), il est donc traité comme un choix opérationnel plutôt qu'un paramètre de gouvernance, et ouvert comme la seule surcharge.