API partenaire et revendeur pour AI Access : clés, utilisation, facturation et contrôles client

Revendre ou intégrer l'accès à l'API IA ne consiste pas seulement à transmettre des demandes à un fournisseur de modèles. Le véritable travail opérationnel commence lorsque chaque client en aval a besoin de ses propres informations d'identification, limites, enregistrements d'utilisation, événements de facturation, contrôles de support et piste d'audit. Une API de partenaire ou de revendeur existe pour gérer ce plan de contrôle.

Pour les agences, les consultants, les créateurs SaaS, les panels de revendeurs et les équipes de plateforme internes, une API de partenaire se trouve au-dessus de l'API d'inférence. L'API d'inférence exécute les complétions de chat, les intégrations, la génération d'images, la transcription ou d'autres appels de modèle. L'API partenaire gère les objets métier autour de ces appels : clients, clés API, groupes de clés, contrôles des dépenses, historique des demandes, transactions de solde, tâches asynchrones, rappels et état du compte.

Cela est important car une clé de fournisseur partagée est facile à démarrer et difficile à survivre. Une fois que plusieurs clients utilisent le même identifiant, l’attribution devient fragile. La réponse aux abus affecte tout le monde. Les limites de taux et les soldes sont regroupés. Les litiges de facturation sont difficiles à enquêter. Une configuration de revendeur résiliente a besoin d'un accès limité au client et d'un grand livre qui peut expliquer ce qui s'est passé, qui l'a causé, combien cela a coûté et quels contrôles ont été appliqués.

Ce qu'une API partenaire doit faire

Une API partenaire est une interface administrative de serveur à serveur pour les systèmes de confiance. Il ne doit pas être exposé directement aux navigateurs, aux applications mobiles, aux plugins ou au code client non fiable. Votre backend, panneau de provisionnement, agent de facturation, robot Telegram, console d'assistance ou portail revendeur appelle l'API partenaire pour créer et gérer l'accès en aval.

Dans un contexte de passerelle AI, l'API partenaire doit prendre en charge au moins quatre responsabilités durables. Premièrement, il doit fournir des informations d’identification à l’échelle du client. Deuxièmement, il doit organiser ces informations d'identification en groupes, plans, projets ou limites de locataires. Troisièmement, il doit exposer les enregistrements d’utilisation et de transactions qui peuvent alimenter les systèmes de facturation et d’assistance. Quatrièmement, il doit fournir des opérations de cycle de vie telles que le gel, le dégel, la rotation, le déplacement et la suppression de clés.

Model Gate est un exemple de ce modèle. Son API partenaire est documentée comme une interface serveur à serveur pour les robots, les panneaux de revendeurs, les systèmes d'approvisionnement internes et les intégrations fiables. Il utilise l'authentification du porteur avec une clé API partenaire et expose les opérations pour les clés API, les groupes, l'utilisation des clés et des groupes, les enregistrements de demandes récentes, les transactions de solde et l'interrogation des résultats asynchrones. Il s'agit de capacités du plan de contrôle, et non de points finaux d'inférence de modèle.

La distinction est importante. Les clients peuvent voir une surface de produit simple telle qu'un portail de revendeur d'API IA, un package API IA en marque blanche ou une intégration IA gérée par une agence. Derrière cette surface, le système partenaire a besoin de suffisamment de structure pour créer des informations d'identification, appliquer les règles du plan, mesurer la consommation et gérer les événements d'assistance sans demander à chaque client de créer des comptes de fournisseur directs.

Quand les agences et les équipes SaaS en ont besoin

Une API partenaire devient nécessaire lorsque l'accès à l'IA fait partie d'un produit ou d'un service géré plutôt que d'une intégration ponctuelle. Les agences peuvent avoir besoin d'une API d'IA pour les agences afin que chaque client dispose d'un budget distinct, d'un rapport d'utilisation distinct et d'un kill switch distinct. Les entreprises SaaS peuvent avoir besoin de clés par locataire, même si les utilisateurs finaux ne les voient jamais, afin que la plateforme puisse attribuer le coût du modèle au bon compte. Les équipes de plate-forme internes peuvent avoir besoin de limites au niveau du projet pour les départements, les environnements ou les applications.

Vous devriez envisager une API de revendeur ou de partenaire si vous avez besoin d'un provisionnement de clés d'API client, de limites de dépenses basées sur un plan, d'analyses d'utilisation déléguées ou d'une suspension et d'une rotation automatisées. Vous devez également en tenir compte lorsque les clients achètent un accès auprès de vous plutôt que directement auprès du fournisseur de modèle sous-jacent. Dans ce cas, la relation client, la facture, le parcours d'assistance et l'application de l'utilisation acceptable appartiennent en partie ou entièrement à votre produit.

Les comptes fournisseurs directs peuvent toujours être le bon choix pour certains clients. Ils donnent à l'acheteur un contrôle direct sur le fournisseur et des factures claires du fournisseur. Mais ils rendent plus difficiles la facturation unifiée des revendeurs, les plafonds stricts au niveau du client, le tri du support et la portabilité des modèles. Les API d'administration des fournisseurs peuvent exposer des projets, des espaces de travail, des clés API, des budgets ou des rapports, mais ces objets ne sont pas toujours équivalents d'un fournisseur à l'autre. Une API partenaire au-dessus d'une passerelle multimodèle vous offre une couche normalisée pour le contrat orienté client.

Le modèle de données de base

Une intégration de partenaire durable commence par un modèle de données local clair. Au minimum, définissez un compte client, un identifiant client externe, un forfait, un mode de facturation, des clés API, des groupes de clés, des limites d'utilisation, des autorisations de modèle, l'état actuel et les métadonnées de support. Ne présumez pas que le propriétaire du compte, le propriétaire de la facturation, le principal des informations d'identification, le client locataire et l'utilisateur final sont la même identité.Dans les environnements de revendeur et SaaS, ils divergent souvent.

Un modèle pratique inclut souvent les objets suivants :

• Client ou locataire : la limite commerciale ou d'application utilisée pour l'attribution et la facturation.
• Clé API : l'identifiant utilisé par un client, une application, un environnement ou un service interne pour appeler l'API d'inférence.
• Limite de groupe ou de plan : un conteneur pour les limites et le modèle partagés. autorisations, règles de tarification ou rapports.
• Enregistrement d'utilisation : un événement normalisé décrivant l'ID de la demande, le client, la clé, le groupe, le modèle, le point de terminaison, le nombre de jetons, le statut, l'horodatage et les composants de coût.
• Transaction de solde : une écriture du grand livre financier pour les crédits, les débits, les ajustements, les remboursements ou les règlements.
• Tâche asynchrone : une tâche modèle soumise qui peut être terminée ultérieurement. et nécessite une interrogation, une gestion des rappels et un état de facturation final.
• Événement d'audit : un enregistrement interne de l'approvisionnement, des modifications de limites, de la rotation des clés, de la suspension, des actions de support et des résultats du rapprochement.

Ce modèle doit vivre dans votre système même si la passerelle expose des objets similaires. Votre base de données locale est l'endroit où vous connectez l'intention commerciale à l'état de la passerelle : quel client a acheté quel forfait, pourquoi une clé a été créée, quelle ligne de facture a utilisé quels événements d'utilisation et ce qui s'est passé lorsqu'un délai d'attente ou un échec de rappel s'est produit.

Workflow de provisionnement

Le provisionnement doit être traité comme une machine d'état, et non comme un simple script de meilleur effort. Un flux de travail typique commence par la création ou le mappage du client dans votre système, la sélection du plan, la création d'une clé de passerelle étendue, l'attribution de la clé à un groupe, l'application de limites et d'autorisations de modèle, le stockage sécurisé uniquement du secret renvoyé et la fourniture de l'accès via un canal approuvé.

Les états utiles incluent en attente, key_created, limits_applied, livré, actif, suspendu, rotation_required et supprimé. Ces états rendent les tentatives et les actions de support compréhensibles. Si la création de clé réussit mais que l'affectation limite expire, le système doit savoir où reprendre. Si un client passe des crédits prépayés à la facturation postpayée, le système doit enregistrer quels contrôles ont changé et quand.

La gestion des informations d'identification mérite une attention particulière. La livraison du secret de la clé API doit être un événement sécurisé unique. N'enregistrez pas de secrets. N'envoyez pas les informations d'identification du fournisseur aux navigateurs des clients ou aux applications mobiles. Stockez uniquement ce qui est nécessaire pour prendre en charge le client et fournissez des chemins de rotation qui permettent aux anciennes et aux nouvelles clés de s'exécuter lors d'un basculement planifié lorsque les charges de travail de production en dépendent.

Pour une conception d'identifiants plus large, les clés de passerelle définies par le client doivent faire partie d'une stratégie plus large de gestion des clés API qui couvre la rotation, le gel, le moindre privilège, la séparation des environnements et la prise en charge. visibilité.

L'idempotence est une fonctionnalité de facturation

L'idempotence n'est pas seulement une subtilité de l'API. Dans l’automatisation des API partenaires, elle protège les clients et les systèmes financiers des effets secondaires en double. Créer une clé deux fois, ajouter des crédits deux fois ou appliquer des limites contradictoires après un délai d'attente peut produire un réel impact sur le client.

La mutation des opérations des partenaires devrait nécessiter des clés d'idempotence stables. Model Gate documente cette attente pour la mutation des requêtes d'API partenaire POST, PATCH et DELETE et demande aux implémenteurs de réessayer la même opération logique avec la même clé d'idempotence après les délais d'attente. Il documente également une fenêtre de conservation de sept jours pour les enregistrements d'idempotence.

La clé doit être dérivée d'une intention commerciale et non d'une nouvelle tentative aléatoire. Par exemple, create-key:customer_123:prod:plan_pro est une opération logique stable. Une nouvelle tentative de la même opération devrait la réutiliser. Une opération ultérieure visant à créer une deuxième clé pour un environnement différent doit utiliser une clé d'idempotence différente.

Votre grand livre d'opérations local doit stocker la méthode de demande, le point de terminaison, la clé d'idempotence, l'ID client externe, le hachage de charge utile, l'ID de demande de passerelle, l'état de la réponse et le résultat final. Cet enregistrement constitue le pont entre votre moteur de workflow et la passerelle. Cela donne également aux équipes d'assistance et financières un moyen de répondre à ce qui s'est passé lorsqu'un employé est tombé en panne, qu'un délai d'attente du réseau s'est produit ou qu'un client prétend qu'un ajustement de crédit a été appliqué deux fois.

Utilisation, mesure et facturation

La facturation basée sur l'utilisation de l'IA doit être basée sur des enregistrements normalisés, et non sur des captures d'écran du tableau de bord ou des factures générales des fournisseurs. Un registre d'utilisation utile comprend l'ID de demande, l'ID client, l'ID de clé, l'ID de groupe, le modèle, le point de terminaison, le mode, le statut, la répartition des jetons et des prix, l'horodatage et l'état de règlement.Le cas échéant, il doit conserver les catégories de jetons telles que l'entrée, la sortie, l'entrée mise en cache, l'utilisation de l'outil, le mode par lots ou les ajustements spécifiques au fournisseur.

L'argent, les crédits, les soldes, les multiplicateurs et les quantités utilisées doivent être analysés sous forme de décimales exactes. Model Gate documente les champs financiers et d'utilisation dans son API partenaire sous forme de chaînes décimales JSON et demande aux implémenteurs d'utiliser l'arithmétique décimale de précision arbitraire plutôt que la virgule flottante binaire. Cette conception évite les petites erreurs d'arrondi qui deviennent visibles dans les factures, les affichages du solde restant et les calculs de marge des revendeurs.

La facturation mesurée par bandes a des exigences similaires : identifiants client explicites, valeurs d'utilisation, horodatages, dimensions et identifiants d'idempotence. Si vous exportez l’utilisation de la passerelle vers un fournisseur de facturation externe, ne réduisez pas trop de détails trop tôt. Vous pouvez facturer sur une unité simplifiée, mais vous avez toujours besoin de suffisamment de provenance pour rapprocher les enregistrements de demandes, équilibrer les transactions, les factures, les remboursements et les tickets d'assistance client.

Pour les équipes qui conçoivent des plans et des marges, la mesure des partenaires se connecte directement à la facturation de l'API IA. La passerelle peut normaliser l'accès aux modèles et les analyses d'utilisation, mais le revendeur a toujours besoin d'un catalogue de prix, de dates d'effet, d'une politique d'arrondi, de règles de taxe et de facturation, ainsi que d'un travail de rapprochement qui compare l'utilisation locale, l'état de la passerelle, les transactions de solde, les événements de rappel et les enregistrements du fournisseur de facturation.

Limites de dépenses, quotas et limites de débit

Les produits des revendeurs nécessitent souvent des contrôles stricts. Les tableaux de bord des fournisseurs peuvent proposer des budgets ou des alertes, mais les alertes ne sont pas identiques à une application stricte. Certaines limites de dépenses pour les projets des fournisseurs sont des seuils souples. Elles notifient ou guident le comportement, mais elles ne peuvent pas arrêter l'utilisation au niveau de la limite client promise par votre produit.

Une API partenaire doit vous permettre d'appliquer des limites par client, clé, groupe, plan ou classe de modèle. Les crédits prépayés sont plus faciles à plafonner car le solde restant est explicite. La facturation postpayée peut s'adapter aux achats des entreprises, mais elle nécessite une détection des anomalies, des contrôles de crédit et des flux de recouvrement plus stricts. Des limites strictes protègent la marge des revendeurs mais peuvent interrompre la charge de travail des clients. Les alertes logicielles réduisent les perturbations mais peuvent permettre des dépenses excessives.

Les limites de tarifs nécessitent également une appropriation claire. Un client peut atteindre une limite au niveau du revendeur, une limite au niveau de la passerelle ou une limite au niveau du fournisseur en amont. Votre documentation destinée aux clients doit expliquer comment gérer les réponses HTTP 429, en particulier le comportement Retry-After. Model Gate documente les réponses de limite de débit avec les en-têtes HTTP 429, Retry-After et X-RateLimit. Les clients doivent reculer en fonction de ces en-têtes au lieu de réessayer immédiatement et de créer des pics de charge ou des dépenses excessives.

Historique, pagination et conservation des demandes

Les enregistrements de demandes récentes sont utiles pour l'assistance, le débogage et le rapprochement à court terme. Ils ne remplacent pas une base de données financière permanente, à moins que la passerelle ne promette explicitement ce modèle de rétention. Traitez les API d’historique des demandes comme des fenêtres opérationnelles. Exportez et conservez les enregistrements dont vous avez besoin pour la facturation, l'audit, l'assistance et l'analyse.

Les API partenaires utilisent généralement la pagination du curseur pour les points de terminaison de collecte. Limite des documents Model Gate plus pagination du curseur opaque et horodatages UTC RFC3339. Les curseurs doivent être traités comme des jetons opaques. Ne les construisez pas manuellement, n’y stockez pas de signification commerciale et ne créez pas de logique de facturation qui prend la forme d’un curseur. Votre exportateur doit se souvenir du dernier point de contrôle réussi, gérer les enregistrements en double en toute sécurité et réconcilier par ID de demande plutôt que par position de page uniquement.

Les fenêtres de conservation affectent également la prise en charge. Si un client pose une question sur une facture datant d'il y a deux mois, votre réponse ne devrait pas dépendre du fait qu'un point de terminaison de demande récente possède toujours l'événement brut. Stockez les métadonnées durables dont vous avez besoin : client, clé, groupe, modèle, ID de demande, statut, quantités utilisées, coût réglé, horodatage et mappage de facture.

Rappels, interrogations et inférence asynchrone

L'inférence asynchrone doit être modélisée comme un workflow de première classe. Les tâches d'images, d'audio, de lots ou d'outils de longue durée peuvent renvoyer un ID de tâche avant que l'utilisation finale et le coût ne soient connus. Le système partenaire doit stocker le travail soumis, interroger ou recevoir des rappels, gérer le traitement, les états terminés, en échec, expirés et annulés, et facturer conformément à la politique de règlement final.

L'interrogation est plus simple à mettre en œuvre et plus facile à tester. Les rappels réduisent la latence et évitent une charge d'interrogation inutile, mais ils nécessitent une vérification de signature, une protection contre la relecture, une déduplication, une gestion des nouvelles tentatives et un traitement des lettres mortes. Les rappels manqués ne doivent pas créer d’écarts de facturation permanents.Un agent de réconciliation doit comparer l'état des tâches asynchrones, les événements de rappel, l'historique des demandes et les transactions de solde.

Model Gate documente l'interrogation des résultats asynchrones dans l'API partenaire et le comportement des rappels dans sa documentation API. Dans un produit revendeur, ces capacités doivent être intégrées dans un modèle de livraison résilient. Les clients doivent voir un état d'avancement clair et le résultat final, tandis que le backend du partenaire préserve les détails opérationnels requis pour l'assistance et la facturation.

Abstraction du fournisseur sans perte de provenance

Une passerelle multimodèle peut masquer les différences inutiles entre les fournisseurs et les clients. Cela est utile lorsque vous souhaitez une interface compatible OpenAI, une seule relation de facturation et un seul modèle opérationnel entre fournisseurs. Mais l’abstraction ne doit pas effacer la provenance. Vous devez toujours savoir quels fournisseurs, modèles, points de terminaison, modes de requête et catégories de jetons ont généré un coût ou un échec.

Cela est particulièrement important lorsque les fournisseurs modifient les prix, abandonnent les modèles, modifient les limites de débit ou exposent des sémantiques d'administration différentes. Les projets OpenAI, les espaces de travail Anthropic, les clés de passerelle API cloud et les clés virtuelles de passerelle IA tierces résolvent tous des problèmes connexes, mais ils n'exposent pas de contrôles identiques. Un plan de contrôle de revendeur a besoin de son propre modèle normalisé et doit traiter les champs spécifiques au fournisseur comme une provenance qui prend en charge le débogage, la réponse aux incidents, la confiance des clients et la planification de la migration.

La conception du plan recoupe également la sélection de modèles d'IA. Les clients peuvent acheter un niveau simple, mais votre backend peut acheminer les demandes entre les modèles en fonction de la qualité, de la latence, du prix, de la région ou de la disponibilité. Conservez suffisamment de détails pour expliquer ces choix lorsque les coûts changent ou que les résultats diffèrent.

Contrôle de l'assistance et des abus

Les workflows d'assistance doivent être conçus avant le premier incident client. Les opérateurs doivent inspecter les métadonnées des demandes récentes, identifier le client et la clé à l'origine d'un pic, geler ou débloquer l'accès, alterner les informations d'identification, déplacer une clé entre les groupes, ajuster les limites lorsque cela est contractuellement approprié et conserver les événements d'audit pour chaque action.

Une bonne console d'assistance n'a pas besoin d'exposer des invites brutes par défaut. L'observabilité axée sur les métadonnées fournit généralement suffisamment de contexte pour la facturation et le tri opérationnel tout en réduisant les risques en matière de confidentialité et de rétention. Si le contenu brut est stocké ou inspecté, définissez des contrôles d'accès, des périodes de conservation, des notifications aux clients et des journaux d'audit.

Les contrôles contre les abus doivent être précis. Le gel d’une clé ne doit pas suspendre les locataires non liés. Un client bruyant ne doit pas épuiser le solde de son compte partagé ou la capacité du fournisseur pour tous les autres clients. Les contrôles au niveau du groupe et au niveau des clés rendent la réponse plus rapide et moins perturbatrice.

Marque blanche, co-marquage ou accès transparent

Les revendeurs doivent décider dans quelle mesure le client connaît la passerelle sous-jacente et les fournisseurs de modèles. Une API IA en marque blanche peut présenter uniquement la marque du revendeur. Un service comarqué peut divulguer la passerelle ou le fournisseur. Une offre d'entreprise transparente peut indiquer la provenance du modèle, les régions du fournisseur et les catégories d'utilisation détaillées.

Il n'y a pas qu'une seule bonne réponse. Masquer les détails peut simplifier le produit client. La divulgation de détails peut améliorer la confiance, l’approvisionnement, l’examen de la conformité et la gestion des incidents. Ce qui compte, c'est la cohérence. La facture, le processus d'assistance, la politique d'utilisation acceptable, le langage de limite de débit et les engagements de traitement des données doivent correspondre à la façon dont l'accès est présenté.

Erreurs courantes

L'échec le plus courant consiste à utiliser une clé API partagée pour de nombreux clients. Cela fonctionne jusqu'à ce qu'il y ait un litige de facturation, un rapport d'abus, un pic de latence, un problème de quota ou un événement de désabonnement des clients. Sans informations d'identification client, chaque enquête devient une conjecture.

Une autre erreur fréquente consiste à réessayer des opérations de mutation sans idempotence. Les délais d'attente sont ambigus. L'opération a peut-être réussi même si votre collaborateur n'a pas reçu de réponse. Des clés d'idempotence stables et un registre d'opérations local évitent les clés en double, les crédits et les changements d'état.

Les erreurs d'arrondi sont également faciles à sous-estimer. L'analyse des champs décimaux et d'utilisation sous forme de nombres à virgule flottante peut créer de petites différences qui s'accumulent entre les factures. Utilisez une arithmétique décimale de précision arbitraire pour les crédits, les soldes, les multiplicateurs et les coûts réglés.

Les équipes font également trop confiance aux budgets des fournisseurs. Les alertes et les limites au niveau du projet peuvent ne pas appliquer les plafonds stricts au niveau du client promis dans un plan de revendeur. Appliquez des limites au niveau de la passerelle ou de la couche partenaire lorsque cela est possible, puis rapprochez l'utilisation réglée une fois terminé.

Enfin, ne construisez pas la facturation uniquement à partir des totaux. Les totaux sont des résumés utiles, mais les factures nécessitent des lignées défendables.Stockez les ID de demande, les ID client, les ID de demande de passerelle, les détails d'utilisation, les enregistrements de transaction, les ID d'événement de facturation et les états de règlement.

Liste de contrôle de mise en œuvre

Commencez par le cycle de vie du client. Définissez la manière dont un client est créé, mis à niveau, suspendu, réactivé, alterné et supprimé. Mappez chaque état aux opérations de l'API partenaire et aux événements d'audit locaux.

Ensuite, concevez le grand livre des opérations. Chaque demande d'API de partenaire en mutation doit avoir une clé d'idempotence stable, un hachage de charge utile, un ID de demande de passerelle le cas échéant, un statut de réponse, un nombre de tentatives et un résultat final. Ce grand livre constitue l'épine dorsale d'une automatisation fiable des API des partenaires.

Créez ensuite l'exportation et le rapprochement de l'utilisation. Exportez les enregistrements de demandes et de transactions selon un calendrier. Utilisez des décimales exactes. Recherchez les événements manquants, les soumissions de facturation en double, les tâches asynchrones non réglées, les échecs de rappel et les incohérences de facture.

Après cela, exposez soigneusement les vues en libre-service des clients. Affichez l'utilisation, le budget restant, les clés actuelles, les options de rotation, les limites et les échecs récents. N’exposez pas les informations d’identification du fournisseur ou les données de locataire non liées. Rendre les actions d'assistance vérifiables et réversibles lorsque cela est possible.

Enfin, documentez les nouvelles tentatives face aux clients et limitez les comportements. Expliquez la gestion de 429, les attentes en matière de rotation des clés, les états des tâches asynchrones, le délai de rapport d'utilisation et la différence entre les plafonds stricts, les alertes logicielles, les limites des revendeurs, les limites de la passerelle et les limites du fournisseur en amont.

Conclusion

Une API de partenaire et de revendeur est le plan de contrôle qui transforme l'accès au modèle d'IA en un produit fiable. Il doit créer des informations d'identification client, les organiser en groupes ou en plans, appliquer des contrôles de dépenses et de tarifs, exposer les enregistrements d'utilisation et de transaction, prendre en charge les flux de travail asynchrones et fournir des opérations de support telles que la rotation, le gel et le rapprochement.

Le principe central est simple : chaque promesse destinée au client nécessite un objet backend durable et une piste d'audit. Si vous promettez une facturation séparée, créez une attribution distincte. Si vous promettez un budget, appliquez-le et rapprochez-le. Si vous réessayez des opérations, rendez-les idempotentes. Si vous facturez l'utilisation, conservez les enregistrements décimaux exacts et la provenance au niveau de la demande.

Les capacités de l'API partenaire de Model Gate sont pertinentes car elles répondent au travail du plan de contrôle autour d'une passerelle multimodèle compatible OpenAI : authentification de serveur à serveur, automatisation des clés API et des groupes, utilisation décimale et champs financiers, historique des demandes, transactions de solde, interrogation des résultats asynchrones, exigences d'idempotence, réponses aux limites de débit, rappels, facturation unifiée, gestion des clés API, analyses d'utilisation et équipe. contrôles. Utilisées avec soin, ces primitives permettent aux agences, aux équipes SaaS et aux revendeurs de regrouper l'accès à l'API IA sans renoncer au contrôle de la facturation ou à la responsabilité opérationnelle.