Emaili që dërgon produkti yt
nga thirrja te përfundimi
Aplikacioni yt dërgon një mesazh dhe OpenEmail e nis nga domeni yt. Çdo thirrje rri pranë çelësit që e bëri, dhe çdo dërgim ka një përfundim për t'u lexuar.
Thirrja përgjigjet me një id mesazhi. Çdo ngjarje që merr pika jote fundore mban të njëjtën id.
Ku nis
Si duket kjo sot.
Posta del nga kodi yt
Faturat, kodet e regjistrimit dhe rivendosjet e fjalëkalimit i dërgon backend-i yt, nuk i shkruan një person.
Pas dërgimit, asgjë nuk kthehet
Një klient thotë se kodi nuk mbërriti kurrë, dhe s'ka asnjë regjistër dorëzimi për ta kontrolluar.
Një çelës i përbashkët, pa regjistër
Çdo shërbim dërgon me të njëjtin sekret, dhe asgjë nuk tregon cila thirrje dështoi e kur.
Si funksionon
Në punë me katër hapa.
- 01
Verifiko domenin
Publiko regjistrimet e shfaqura te cilësimet, dhe domeni bëhet i gjelbër kur ato përputhen.
- 02
Lësho një çelës të kufizuar
Kufizoje çelësin te adresat dhe domenet nga të cilat mund të dërgojë, dhe cakto me një rol se ku arrin.
- 03
Dërgo mesazhin
Një thirrje emërton shabllonin, vlerat e tij dhe marrësin, dhe një riprovë nuk e dërgon dot dy herë.
- 04
Merr webhook-un, lexo regjistrin
Pika jote fundore dëgjon çdo ngjarje sipas ID-së së mesazhit, dhe regjistri tregon dorëzuar, kthyer ose dështim.
Mbi çfarë mbështetet
Pjesët që bëjnë punën.
Mbështetet në një API të dokumentuar me çelësa të kufizueshëm, një SDK të tipizuar, webhook-e te pika jote fundore, shabllone me versione, dhe regjistrimet që qëndrojnë pas domenit tënd dërgues.
Një API HTTP e dokumentuar me çelësa që lëshohen, kufizohen në fushëveprim dhe shfuqizohen.
Së pari një klient TypeScript, pastaj të tjerët.
I thonë pikës suaj fundore kur mbërrin posta, në vend që t'ju vënë të pyesni vazhdimisht.
Një trup i shkruar një herë, me versione, dhe i dërguar shumë herë: nga hartuesi, nga kodi juaj ose nga një agjent.
Një shenjë pranë dërguesit kur regjistrimet e publikuara të domenit dërgues përputhen.
Një regjistrim fillestar p=none, i shtypur për ta kopjuar ose i shkruar nga një sinkronizim, kurrë i shtrënguar për ju.
v=DMARC1; p=none; rua=…
Në praktikë
Çdo pjesë, hap pas hapi.
Katër faqe më të shkurtra e kalojnë rrugën: dërgimi nga kodi yt, leximi i regjistrit të thirrjeve, çfarë ndodhi pas dërgimit, dhe posta brenda një ekzekutimi testues, që ende do të vijë.
Dërgo kupona, kode dhe lidhje rivendosjeje nga kodi yt, dhe mëso kur mbërrijnë.
Çdo thirrje e një çelësi, çdo webhook i dërguar, me kodin dhe kohën.
Jepi çdo ekzekutimi testi adresën e vet dhe lexo emailin që merr.
Pyetje
Të bëra para regjistrimit.
Çfarë e ndalon një riprovë ta dërgojë emailin dy herë?
Një thirrje emërton shabllonin, vlerat e tij dhe marrësin, dhe një riprovë e saj nuk dërgon dot dy herë. Thirrja përgjigjet me një ID mesazhi, dhe çdo ngjarje që dëgjon pika jote fundore mbart të njëjtën ID.
A mund të shoh çfarë ndodhi pas dërgimit?
Po. Çdo dërgim lexohet si dorëzuar, kthyer, ankesë ose dështim, sipas ditës, burimit dhe adresës dërguese, dhe regjistri i kërkesave mban metodën, shtegun, kodin e statusit dhe kohëzgjatjen për çdo thirrje të një çelësi.
A ka SDK për gjuhën time?
Ende jo, në shumicën e rasteve. Klienti i tipizuar është së pari për TypeScript dhe të tjerët vijnë më pas, ndaj tani për tani çdo gjuhë tjetër e thërret drejtpërdrejt API-n HTTP të dokumentuar.
Afër
Punë të tjera për të njëjtën kuti.
Çdo biletë, regjistër ose klient mund të ketë adresën e vet. Posta e dërguar aty arrin te pika jote fundore si ngjarje e nënshkruar, dhe kodi yt përgjigjet si ajo adresë.
Jepi një agjenti adresën e vet dhe një çelës të kufizuar te çfarë mund të bëjë. Ai lexon, etiketon, harton dhe dërgon, dhe çdo thirrje e tij regjistrohet.
Shkruaje një herë si shabllon. Dërgoje nga hartuesi, nga kodi yt ose në një ditë që e zgjedh ti, pastaj lexo çfarë ndodhi më pas.
