Çelësat API
`keys->list`, `listAll`, `iterate`, `get`, `create`, `update`, `delete`, `rotate` dhe `revoke`, si dhe lexuesit e regjistrit të kërkesave, të aktivitetit dhe të statistikave.
Çdo metodë
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 dhe rotate janë të vetmet thirrje që kthejnë një sekret, te token, një herë. Çdo lexim kthen në vend të tij maskedKey. update e fik dhe e ndez një çelës me enabled, që është alternativa e kthyeshme e revoke, dhe delete heq vetëm një çelës që është revokuar: çdo çelës tjetër jep një 409 not_revoked, të hedhur si ConflictException. Leximi kërkon keys:read dhe çdo ndryshim kërkon keys:manage.
list kthen një OpenEmail\Result\Page, listAll i kthen të gjithë çelësat në një array të vetëm, dhe iterate kthen një Generator që jep çelësat një nga një. create dhe update e marrin trupin si një array të vetëm me emrat e API-së, dhe revoke merr një array opsional me reason. Një token aksesi OAuth i arrin këto thirrje vetëm kur personi që lidhi aplikacionin është pronari i hapësirës së punës. Token-i i kujtdo tjetër merr një PermissionException me errorCode të vendosur në owner_only.
Paketa nuk e riprovon kurrë create ose rotate. Një riprovim pas një përgjigjeje të humbur do të krijonte një çelës të dytë, ose do ta zhvlerësonte sekretin që ktheu përpjekja e parë. update dhe revoke riprovohen pas një dështimi të rrjetit, sepse përsëritja e tyre e lë të njëjtin çelës, ndërsa delete jo.
Kurrë më i gjerë se thirrësi
Një çelës nuk krijon dhe nuk arrin kurrë një çelës më të gjerë se vetja. Fushat, roli, skadimi, modaliteti dhe fusha e dërgimit duhet të qëndrojnë të gjitha brenda çelësit që thërret, përndryshe thirrja hedh një PermissionException me errorCode të vendosur në beyond_caller_authority, dhe param emërton boshtin. Një çelës i ngushtuar në disa domene ose adresa sheh vetëm çelësat brenda fushës së vet të dërgimit. rotate mbi çelësin që thërret funksionon edhe me keys:write, si $client->me->rotate().
Verifikimi shtesë nuk mund të zbatohet në një thirrje të bërë me çelës, ndaj keys:manage është një kredencial që krijon kredenciale. Jepjani vetëm një automatizimi që lëshon çelësa, jepini atij çelësi një rol, një fushë dërgimi dhe një skadim, dhe ndiqni listWorkspaceActivity, ku gjithçka që bën regjistrohet në emër të tij.
Regjistri i kërkesave dhe aktiviteti
$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 dhe listActivity lexojnë një çelës, ndërsa listWorkspaceRequests dhe listWorkspaceActivity lexojnë çdo çelës ose ata që emërton keyIds:, si array ose si një string i vetëm i ndarë me presje. Secila ka pranë një binjak listAll dhe një iterate, si listAllRequests dhe iterateRequests. Marrin since: dhe until: si një DateTimeInterface ose një string ISO 8601, dhe lexuesit e kërkesave marrin edhe failedOnly:.
stats lexon çfarë bënë çelësat brenda një periudhe: postën që dërguan dhe çfarë u bë me të, thirrjet e refuzuara, kërkesat që bënë dhe rrugët që thirrën. Merr të njëjtat keyIds:, since: dhe until:, si dhe grain: dhe offsetMinutes:, mbulon 30 ditët deri tani kur nuk caktoni periudhë, dhe kërkon emails:read krahas keys:read.
until: duhet të jetë më vonë se since:, përndryshe thirrja hedh një InvalidRequestException me errorCode të vendosur në invalid_parameter dhe param të vendosur në until. Një DateTimeInterface dërgohet në UTC, ndërsa një string dërgohet ashtu siç është shkruar, ndaj duhet të jetë një vulë kohore ISO 8601 si 2026-09-01T00:00:00Z.