Tudásbázis
REST API
Dokumentált HTTP API kibocsátható, hatókörözhető és visszavonható kulcsokkal.
Részletek
- Bekapcsolva, mindenhol. Az API 104 dokumentált műveletet szolgál ki 68 útvonalon (e-mailek, beszélgetések, piszkozatok, címkék, kapcsolatok, célcsoportok, domainek, sablonok, szabályok, szerepkörök, tagok, beállítások, naptár, követés, webhookok és a fiók) egy rögzített OpenAPI 3.1 dokumentum mögött, amelyet kulcs nélkül is elolvashatsz a GET /openapi.json végponton. A hozzáférésről az a munkaterületi kulcs dönt, amelyet a Beállításokban bocsátasz ki.
- A tartósság, amelyre ez korábban várt, elkészült. A küldés mindennek a kiküldése előtt kiír egy sort, msg_ alakú nyilvános azonosítóval, amelyet 24 hexadecimális karakter követ, és a GET /emails/{id} feloldja azt, az /events pedig a címzettenkénti nyomvonalat, a /tracking a megnyitásokat és a kattintásokat adja. Az 1–255 karakteres Idempotency-Key kulcsot a kulcs és az API-kulcsod együttesére vonatkozó egyedi index alapján foglaljuk le, így egy időtúllépés utáni újrapróbálkozás az első eredményt adja vissza Idempotency-Replayed: true jelzéssel, ahelyett hogy kétszer küldene. A kulccsal indított küldés 200 választ ad, amint lezárult, és 202-t, amíg sorban áll vagy időzítve van.
- A kulcsokat a Beállítások → API-kulcsok alatt hozod létre, hatókörözöd, forgatod és vonod vissza. A konzol által kibocsátott minden kulcs oe_live_ típusú. Az oe_test_ előtagot az ellenőrző és a küldési útvonal is érti – ott a teszt módú küldést rögzítjük és elküldöttként nyugtázzuk anélkül, hogy valaha is elérne egy szállítóréteget –, de egyelőre semmi nem tud ilyet kibocsátani, és ha a lehetőséget azelőtt kínálnánk fel, hogy a semmit nem tevő szállítóréteg a Durable Object fölé kerül, olyan tesztkulcsot adnánk a kezedbe, amely valóban kézbesít. Egy kulcs legfeljebb 25 teljes domainre és 50 egyedi címre kiterjedő küldési hatókört hordoz, ahol a teljes domain a később hozzáadott címekre is kiterjed, továbbá egy opcionális, 1 és 3650 nap közötti lejáratot és opcionálisan egy szerepkört. A szerepkör felső korlát, nem pedig második engedély: a GET /ping visszaadja a kulcson lévő hatóköröket és azokat is, amelyeket a szerepkör meghagyott neki, így a 403 válasznak egy olyan hatókörre, amelyet a kulcsod egyértelműen megnevez, látható oka van. A visszavonás frissítés, nem törlés, így egy későbbi hívás revoked_api_key választ kap ahelyett, hogy egyszerűen ne tudna hitelesíteni. A forgatás a titkot leszámítva mindent megtart a kulcsból: az azonosító, a hatókörök, a küldési hatókör és a kéréstörténet tovább él, a régi titok abban a pillanatban megszűnik, amint az új létrejön, és a keys:write jogosultságot birtokló kulcs az API-n keresztül önmagát is forgathatja. Ugyanezek a listázó, forgató, visszavonó és engedélyező műveletek az MCP-szerveren is elérhetők mindenkinek, akinek a szerepköre kezelheti a kulcsokat.
- Ami valóban hiányzik: az API-nak nincs saját feltöltési végpontja. A beágyazott mellékletek base64 formában mennek, összesen 5 MB-os korláttal, a nagyobb fájlt pedig úgy küldöd el, hogy egy már a munkaterületen lévő fájlt nevezel meg az azonosítójával, és az letöltési hivatkozásként utazik. A visszapattanásokat a postafiók kezeli, nem a küldési napló: a kézbesítési jelentést feldolgozzuk, Message-ID alapján az eredetihez rendeljük, címkével látjuk el a beszélgetésen, és email.bounced webhookként küldjük tovább, de semmi nem ír vissza a küldési sorba, amelynek állapotában nincs bounced érték, így a GET /emails felől nézve a visszapattant üzenet továbbra is elküldöttként olvasható. Az alkalmazás szerkesztőjéből küldött levél sem jelenik meg a GET /emails végponton, mert a szerkesztő nem ugyanazon a küldési útvonalon ír.