Ende e pandërtuar

Ta zbulosh duke provuar është më keq se të të thuhet. Asgjë nga këto nuk ekziston sot:

• —Një dërgesë provohet deri në pesë herë: sapo ndodh, pastaj pas 1 minute, 5, 25 dhe 2 orësh. Çdo përpjekje regjistrohet dhe lexohet përmes GET /webhooks/{id}/deliveries, secila me attempt dhe maxAttempts të vetin. Riprovimi ndalon herët kur përgjigjja tregon se përsëritja nuk ka kuptim: çdo gjë tjetër veç 408, 425, 429 ose një 5xx merret si refuzim i qëllimshëm. Ende nuk ka endpoint për riluajtje, ndaj një endpoint i rënë për më gjatë se ajo dritare ka një hendek, dhe regjistri i dërgesave është vendi ku e gjeni.
• —Një mesazh i kthyer prapsht lexohet ende si sent përmes GET /emails: raporti i dërgesës përputhet me origjinalin dhe etiketohet te biseda, por asgjë nuk i shkruhet prapa rreshtit të dërgimit, statusi i të cilit nuk ka gjendje për mesazhe të kthyera. Bllokimi që ai ushqen është real: një kthim i përhershëm ose një ankesë e vendos adresën te lista e bllokimeve të kësaj hapësire pune dhe dërgimi i radhës drejt saj refuzohet. Është regjistrimi i dërgimit ai që nuk mëson.
• —Nuk ka kufizues të përgjithshëm të shpejtësisë së kërkesave. Ekzistojnë dy kufij të numëruar dhe të dy përgjigjen me 429: një hapësirë pune që e shpenzon kuotën mujore të dërgimeve që përfshin plani i saj merr send_quota_exceeded te çdo dërgim i mëtejshëm deri më një të muajit, ndërsa krijimi i kutive postare të përkohshme kufizohet në gjashtë në orë dhe tridhjetë në ditë për klient, me too_many_inboxes. Asnjëri nuk mbart Retry-After. Një kufizues mbi shpejtësinë e leximeve dhe shkrimeve të zakonshme është një mungesë e jo një premtim, dhe do të korrigjohet.
• —Nuk ka endpoint NGARKIMI bashkëngjitjesh te API-ja. Bashkëngjitjet inline janë base64 dhe kufizohen në 5 MB për të gjithë mesazhin. Një skedar më i madh dërgohet si { fileId }, që emërton një skedar tashmë në hapësirën e punës, dhe udhëton si lidhje shkarkimi. Leximi i bashkëngjitjeve nga posta e marrë funksionon.