Clés API
`keys->list`, `listAll`, `iterate`, `get`, `create`, `update`, `delete`, `rotate` et `revoke`, ainsi que les lecteurs du journal des requêtes, de l'activité et des statistiques.
Toutes les méthodes
use OpenEmail\Constants\ApiScopes; $key = $client->keys->create([ 'name' => 'Billing sender', 'scopes' => [ApiScopes::EMAILS_SEND], 'domainAllowlist' => ['billing.acme.com'], 'expiresInMinutes' => 60 * 24 * 90,]); file_put_contents('.openemail-billing-key', $key['token']); $client->keys->update($key['id'], ['enabled' => false]); $rotated = $client->keys->rotate($key['id']);file_put_contents('.openemail-billing-key', $rotated['token']); $client->keys->revoke($key['id'], ['reason' => 'Replaced']);$client->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 : toute autre clé donne un 409 not_revoked, levé sous la forme d'une ConflictException. Lire demande keys:read et chaque modification keys:manage.
list renvoie une OpenEmail\Result\Page, listAll renvoie toutes les clés dans un seul tableau, et iterate renvoie un Generator qui fournit les clés une par une. create et update prennent le corps sous forme d'un seul tableau aux noms de l'API, et revoke prend un tableau facultatif avec reason. Un jeton d'accès OAuth n'atteint ces appels que lorsque la personne qui a connecté l'application est propriétaire de l'espace de travail. Celui de toute autre personne reçoit une PermissionException avec errorCode à owner_only.
Le package ne réessaie jamais create ni rotate. Un réessai après une réponse perdue créerait une deuxième clé, ou invaliderait le secret renvoyé par la première tentative. update et revoke sont réessayés après une panne réseau, car les répéter laisse la même clé, et delete ne l'est pas.
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 lève une PermissionException avec errorCode à beyond_caller_authority, et param nomme l'axe. 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 $client->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 listWorkspaceActivity, où tout ce qu'elle fait lui est attribué.
Journal des requêtes et activité
$failures = $client->keys->listRequests( '4c1b257a66287fd113bd89d0', failedOnly: true, since: new \DateTimeImmutable('-1 day'),);echo count($failures), PHP_EOL; foreach ($client->keys->iterateWorkspaceActivity() as $change) { echo $change['keyName'], ' ', $change['type'], ' ', $change['actor']['label'] ?? 'system', PHP_EOL;}listRequests et listActivity lisent une clé, et listWorkspaceRequests et listWorkspaceActivity lisent toutes les clés ou celles que nomme keyIds:, sous forme de tableau ou d'une seule chaîne séparée par des virgules. Chacune a un jumeau listAll et un jumeau iterate à côté, comme listAllRequests et iterateRequests. Elles prennent since: et until: sous forme de DateTimeInterface ou de chaîne ISO 8601, et les lecteurs de requêtes prennent aussi failedOnly:.
stats lit ce que les clés ont fait dans une fenêtre de temps : le courrier qu'elles ont envoyé et ce qu'il est devenu, les appels refusés, les requêtes qu'elles ont faites et les routes qu'elles ont appelées. Il prend les mêmes keyIds:, since: et until:, plus grain: et offsetMinutes:, couvre les 30 jours précédant le moment présent quand vous ne nommez aucune fenêtre, et demande emails:read en plus de keys:read.
until: doit être postérieur à since:, sinon l'appel lève une InvalidRequestException avec errorCode à invalid_parameter et param à until. Un DateTimeInterface est envoyé en UTC, et une chaîne est envoyée telle quelle : elle doit donc être un horodatage ISO 8601 comme 2026-09-01T00:00:00Z.