Betrouwbare tijdelijke‑inbox API‑automatisering

De onbetrouwbare versie van een e‑mailtest is kort: maak een adres aan, wacht vijf seconden, lees het eerste bericht en hoop dat het bij deze uitvoering hoort.

De betrouwbare versie blijft eenvoudig, maar behandelt levering als asynchroon. Het maakt een uniek adres, registreert een starttijd, pollt binnen een deadline, matcht het beoogde bericht, valideert de productactie en rapporteert voldoende context wanneer iets faalt.

Houd de API‑sleutel uit de URL

Stuur de GPTMail‑sleutel in de X-API-Key‑header. Plaats deze niet in ?api_key=‑query‑parameters. URL’s worden routinematig opgeslagen in de browsergeschiedenis, toegangslogboeken, monitoringsystemen en referrer‑data.

X-API-Key: YOUR_API_KEY

Sla de sleutel op in je CI‑secret‑manager en maskeer deze in logboeken. Een openbare dagelijkse sleutel is handig voor verkenning; gecontroleerde geautomatiseerde suites moeten een sleutel gebruiken waarvan je de quota en het gebruik kunt volgen.

De huidige eindpunten en responsvoorbeelden worden bijgehouden op de GPTMail API documentatiepagina.

Eén adres per uitvoering

Genereer een nieuw adres voor elke onafhankelijk uitvoerbare test. Baseer de correctheid niet op een inbox die door een volledige testsuite wordt gedeeld.

Registreer het adres, scenario‑ID, omgeving en starttijd van de test. Deze waarden stellen je in staat verouderde berichten af te wijzen en botsingen te diagnosticeren zonder berichtgeheimen te loggen.

Poll tegen een deadline, niet tegen een vaste wachttijd

De e‑mailbezorgtijd varieert. Een vaste wachttijd van vijf seconden is zowel verspilling wanneer de levering snel is als onbetrouwbaar wanneer deze traag is.

Gebruik een begrensde lus:

deadline = now + 90 seconds
delay = 2 seconds

while now < deadline:
  messages = list inbox
  candidate = newest message matching sender, subject, and start time
  if candidate exists:
    read candidate and continue the product test
  wait delay with a small random jitter
  delay = min(delay * 1.5, 10 seconds)

De deadline maakt deel uit van het testcontract. Een wachtwoordreset‑flow kan een andere limiet nodig hebben dan een bulk‑nieuwsbriefpreview. Houd de limiet expliciet zodat een trage afhankelijkheid niet stilletjes de hele CI‑taak verlengt.

Match nauwkeurig

‘Eerste bericht in de inbox’ is geen bruikbare selector. Match meerdere signalen:

• ontvanger is gelijk aan het voor deze uitvoering aangemaakte adres;
• aanmaaktijd is later dan de trigger‑tijd;
• afzender behoort tot de verwachte service;
• onderwerp of berichttype komt overeen met de flow;
• de bericht‑ID is nog niet eerder gebruikt.

Wanneer de afzender meerdere codes kan uitgeven, selecteer dan het nieuwste overeenkomende bericht. Bewaar de ID in de testoutput zodat retries deze niet per ongeluk opnieuw gebruiken.

Alleen lezen na een lijstmatch

Inbox‑listing moet de goedkope ontdekkingsstap zijn. Haal het volledige bericht alleen op voor de geselecteerde kandidaat. Dit vermindert onnodig werk en voorkomt het parseren van ongerelateerde promotionele e‑mail.

Valideer de zakelijke uitkomst, niet alleen de aanwezigheid van een zescijferige string. Verstuur de code of open de verwachte link, en controleer vervolgens of het account de juiste status bereikt.

Behandel rate‑limieten als een signaal

Als de API een quota‑ of rate‑limit‑respons teruggeeft, stop dan de huidige poging en toon de reset‑informatie. Agressieve retries veranderen een duidelijk capaciteitsignaal in ruis en kunnen ongerelateerde tests vertragen.

Beperk de gelijktijdigheid bij de testrunner, vooral wanneer een suite veel adressen tegelijk aanmaakt. Een kleine werkerspool is makkelijker te debuggen dan honderden gelijktijdige polling‑lussen.

Opruimen zonder fouten te verbergen

Opruimen moet plaatsvinden nadat bewijs is vastgelegd. Bij succes, verwijder berichten of laat een korte retentie ze afhandelen. Bij falen, bewaar het adres en de bericht‑ID in beschermde CI‑artefacten lang genoeg voor onderzoek, en verwijder ze daarna.

Print nooit verificatiecodes, privé‑links of volledige HTML‑bodies in openbare build‑logboeken.

Maak retries idempotent

Herhaal de test als een nieuwe uitvoering met een nieuw adres. Ga er niet van uit dat het herhalen van dezelfde aanvraag tegen hetzelfde account en dezelfde inbox vanuit een schone staat start. De afzender kan oude codes ongeldig maken, herhaalde aanvragen beperken of dubbele uitnodigingen afwijzen.

Als een netwerkverzoek time‑out, onderscheid dan ‘geen respons ontvangen’ van ‘operatie heeft niet plaatsgevonden’. Controleer de waarneembare staat voordat je een destructieve retry uitvoert.

Rapporteer het punt van falen

Een bruikbare automatiseringsfout identificeert een van deze fasen:

1. adresgeneratie mislukt;
2. productactie mislukt vóór het in de wachtrij plaatsen van de e‑mail;
3. geen overeenkomend bericht arriveerde vóór de deadline;
4. bericht arriveerde maar de inhoud kwam niet overeen;
5. verificatieactie mislukt;
6. opruimen mislukt.

Die classificatie verandert een intermitterende ‘e‑mailtest mislukt’ in werk dat een team kan oppakken.

Voor de grotere testmatrix, lees Een echt e‑mailtestplan. Voor leveringsdiagnose, gebruik Verificatie‑e‑mail komt niet aan: vind de defecte stap.