Aller à la documentation
Python

Clés API

`keys.list`, `list_all`, `iterate`, `get`, `create`, `update`, `delete`, `rotate` et `revoke`, ainsi que les lecteurs du journal des requêtes et de l'activité.

Toutes les méthodes

keys.py
from pathlib import Path from openemail import openemail key = openemail.keys.create({    'name': 'Billing sender',    'scopes': ['emails:send'],    'domainAllowlist': ['billing.acme.com'],    'expiresInMinutes': 60 * 24 * 90,}) secret = Path('.openemail-billing-key')secret.touch(mode=0o600)secret.write_text(key['token']) openemail.keys.update(key['id'], {'enabled': False}) rotated = openemail.keys.rotate(key['id'])secret.write_text(rotated['token']) openemail.keys.revoke(key['id'], {'reason': 'Replaced'})openemail.keys.delete(key['id'])

create et rotate sont les seuls appels qui renvoient un secret, dans token, une seule fois. Chaque lecture renvoie maskedKey à la place. update désactive et réactive une clé avec enabled, l'alternative réversible à revoke, et delete ne supprime qu'une clé déjà révoquée. Lire demande keys:read et chaque modification keys:manage.

Le client ne réessaie jamais create ni rotate. Une nouvelle tentative après une réponse perdue créerait une deuxième clé, ou invaliderait le secret que la première tentative a renvoyé. update et revoke sont réessayés comme des lectures, car les répéter laisse la même clé, mais pas delete.

Jamais plus large que l'appelant

Une clé ne crée ni n'atteint jamais une clé plus large qu'elle-même : portées, rôle, expiration, mode et portée d'envoi doivent tous rester à l'intérieur de la clé qui appelle, sinon l'appel est refusé avec 403 beyond_caller_authority. Une clé restreinte à certains domaines ou adresses ne voit que les clés à l'intérieur de sa propre portée d'envoi. rotate sur la clé qui appelle fonctionne aussi avec keys:write, comme me.rotate().

La vérification renforcée ne peut pas s'appliquer à un appel fait avec une clé, donc keys:manage est un identifiant qui fabrique des identifiants. Ne la donnez qu'à une automatisation qui émet des clés, donnez à cette clé un rôle, une portée d'envoi et une expiration, et surveillez list_workspace_activity, où tout ce qu'elle fait lui est attribué.

Journal des requêtes et activité

key_logs.py
from datetime import datetime, timedelta, timezone from openemail import openemail failures = openemail.keys.list_requests(    '4c1b257a66287fd113bd89d0',    failed_only=True,    since=datetime.now(timezone.utc) - timedelta(days=1),)for request in failures['items']:    print(request['status'], request['method'], request['path']) for change in openemail.keys.iterate_workspace_activity():    actor = change['actor']    print(change['keyName'], change['type'], actor['label'] if actor else None)

list_requests et list_activity lisent une clé, list_workspace_requests et list_workspace_activity lisent toutes les clés ou celles que nomme key_ids, et chacune a un list_all_… et un iterate_… à côté. Elles acceptent since et until, et les lecteurs de requêtes acceptent aussi failed_only.

since et until acceptent un datetime ou une chaîne ISO 8601. Un datetime est envoyé en UTC ; s'il est naïf, il est d'abord interprété comme une heure locale.

Référence