Çelësat API

GET /keys rendit çdo çelës që thirrësi mund të shohë, më të rinjtë së pari dhe faqe pas faqeje, me statusin, scope-t, rolin, fushën e dërgimit, përdorimin e fundit dhe kush e krijoi dhe e ndryshoi së fundi. GET /keys/{id} lexon një. Asnjë lexim nuk kthen kurrë një sekret: maskedKey mjafton për të dalluar dy çelësa. Të dyja kërkojnë keys:read.

{  "object": "api_key",  "id": "4c1b257a66287fd113bd89d0",  "name": "Billing sender",  "maskedKey": "oe_live_4c1b…kX7a",  "status": "active",  "scopes": ["emails:send"],  "roleId": null,  "domainAllowlist": ["billing.acme.com"],  "expiresAt": "2026-12-22T09:00:00.000Z",  "lastUsedAt": "2026-09-23T08:14:02.000Z",  "createdBy": { "kind": "apiKey", "name": "API key Provisioner", "label": "API key Provisioner" }}

• —POST /keys krijon një çelës dhe kthen sekretin e tij në token, një herë. Nëse lihen jashtë, scope është emails:send dhe roli, fusha e dërgimit dhe skadimi janë ato të thirrësit.
• —PATCH /keys/{id} riemërton një çelës, zëvendëson scope-t ose fushën e dërgimit dhe e fik e ndez me enabled. Fikja është zgjedhja e kthyeshme: çelësi ruan gjithçka dhe refuzohet me inactive_api_key derisa të ndizet sërish.
• —POST /keys/{id}/rotate i jep një çelësi një sekret të ri dhe e kthen një herë. Sekreti i vjetër ndalon së punuari në çastin kur kthehet thirrja.
• —POST /keys/{id}/revoke e nxjerr një çelës përgjithmonë nga përdorimi, me një reason opsionale. DELETE /keys/{id} pastaj e heq nga lista dhe ruan historikun e tij.
• —Secila prej tyre kërkon keys:manage. Rrotullimi i vetë çelësit që thërret funksionon edhe me keys:write, pikërisht si POST /keys/self/rotate.

Çdo ndryshim kontrollohet kundrejt çelësit që e bën. Një çelës që do të përfundonte jashtë thirrësit në çfarëdo boshti refuzohet me 403 beyond_caller_authority, dhe param emërton boshtin:

• —Scope-t: vetëm ato që mban thirrësi pasi i ka ngushtuar roli i vet.
• —Roli: një thirrës i kufizuar nga një rol mund të krijojë dhe menaxhojë vetëm çelësa të kufizuar nga i njëjti rol.
• —Skadimi: një thirrës që skadon mund të krijojë dhe menaxhojë vetëm çelësa që nuk skadojnë më vonë.
• —Modaliteti: një çelës testi arrin vetëm çelësa testi.
• —Fusha e dërgimit: vetëm domene dhe adresa brenda asaj të thirrësit, dhe mbajtja e një adrese nuk mbulon kurrë gjithë domenin e saj.

Konsola ju kërkon të verifikoheni sërish para se të krijojë ose rrotullojë një çelës. Një thirrjeje të bërë me çelës nuk mund t’i kërkohet kjo, ndaj keys:manage është një kredencial që krijon kredenciale: një çelës i rrjedhur që e mban mund të krijojë çelësa të vetët, deri në shtrirjen e vet, që vazhdojnë të punojnë pasi ai revokohet.

• —Jepjani keys:manage vetëm një automatizimi, puna e të cilit është lëshimi i çelësave, kurrë një çelësi që dërgon postë.
• —Ngushtojeni atë çelës: një rol, një fushë dërgimi dhe një skadim. Gjithçka që krijon i trashëgon të treja dhe nuk mund t’i tejkalojë kurrë.
• —Ndiqni GET /keys/activity. Çdo çelës që krijon, ndryshon ose revokon regjistrohet në emër të tij, ndaj një rrjedhje duket si çelësa që nuk i prisnit.
• —keys:read e nxjerr regjistrin e kërkesave, përfshirë adresat IP dhe user agent-ët. Trajtojeni si akses auditimi.

GET /keys/requests dhe GET /keys/{id}/requests lexojnë çdo thirrje të autentifikuar që bëri një çelës, më të rejat së pari: metoda, shtegu, statusi, kodi i gabimit, kohëzgjatja, IP dhe user agent, kurrë trupin ose query string-un. keyIds, failedOnly, since dhe until janë filtrat që ofron konsola. GET /keys/activity dhe GET /keys/{id}/activity lexojnë çfarë u ndodhi çelësave, me actor që emërton kush e bëri, si @username ose API key <name>. Asgjë nuk krasitet, dhe një çelës i fshirë ruan historikun e vet.