ca

Automatització fiable de l'API de bústia temporal

Construeix proves deterministes d'inscripció i restabliment de contrasenya amb adreces úniques, sondeig limitat, coincidència precisa de missatges, gestió segura de claus i evidència útil d'errors.

17 de jul. 2026

Un bucle d'automatització compacte per generar, rebre, comprovar i netejar una bústia

La versió poc fiable d'una prova de correu electrònic és curta: crear una adreça, esperar cinc segons, llegir el primer missatge i esperar que pertanyi a aquesta execució.

La versió fiable continua sent senzilla, però tracta l'entrega com a asíncrona. Crea una adreça única, registra l'hora d'inici, fa sondeigs dins d'un termini, coincideix amb el missatge esperat, valida l'acció del producte i informa prou context quan alguna cosa falla.

Mantingues la clau de l'API fora de l'URL

Envia la clau de GPTMail a la capçalera X-API-Key. No la posis en paràmetres de consulta ?api_key=. Les URL es guarden habitualment en l'historial del navegador, registres d'accés, sistemes de monitoratge i dades de referència.

X-API-Key: YOUR_API_KEY

Desa la clau al gestor de secrets del teu CI i amaga-la en els registres. Una clau pública diària és convenient per a l'exploració; les suites d'automatització controlades haurien d'utilitzar una clau de la qual puguis seguir la quota i l'ús.

Els punts finals i exemples de resposta actuals es mantenen a la pàgina de documentació de l'API de GPTMail.

Una adreça per execució

Genera una adreça nova per a cada prova executable independentment. No dedueixis la correcció d'una bústia compartida per tot un conjunt de proves.

Registra l'adreça, l'ID de l'escenari, l'entorn i l'hora d'inici de la prova. Aquests valors et permeten rebutjar missatges obsolets i diagnosticar col·lisions sense registrar secrets dels missatges.

Sondeja fins a un termini, no amb una pausa fixa

El temps d'entrega del correu electrònic varia. Una pausa fixa de cinc segons és ineficient quan l'entrega és ràpida i poc fiable quan és lenta.

Utilitza un bucle limitat:

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)

El termini pertany al contracte de la prova. Un flux de restabliment de contrasenya pot necessitar un límit diferent d'una vista prèvia d'un butlletí massiu. Mantén el límit explícit perquè una dependència lenta no allargui silenciosament tota la tasca del CI.

Coincideix amb precisió

«Primer missatge a la bústia» no és un selector útil. Coincideix diversos senyals:

  • el destinatari és igual a l'adreça creada per a aquesta execució;
  • l'hora de creació és posterior a l'hora del desencadenament;
  • l'emissor pertany al servei esperat;
  • l'assumpte o el tipus de missatge coincideix amb el flux;
  • l'ID del missatge encara no s'ha consumit.

Quan l'emissor pot emetre diversos codis, selecciona el missatge coincident més recent. Conserva el seu ID a la sortida de la prova perquè els reintents no el reutilitzin accidentalment.

Llegeix només després d'una coincidència a la llista

Llistar la bústia hauria de ser l'etapa de descobriment econòmica. Recupera el missatge complet només per al candidat seleccionat. Això redueix treball innecessari i evita analitzar correus promocionals no relacionats.

Valida el resultat del negoci, no només la presència d'una cadena de sis dígits. Envia el codi o obre l'enllaç esperat, i després verifica que el compte arribi a l'estat correcte.

Gestiona els límits de taxa com a senyal

Si l'API retorna una resposta de quota o límit de taxa, atura l'intent actual i mostra la informació de reinici. Reintents agressius converteixen una senyal clara de capacitat en soroll i poden retardar proves no relacionades.

Limita la concurrència al corredor de proves, especialment quan una suite crea moltes adreces alhora. Un petit grup de treballadors és més fàcil de depurar que centenars de bucles de sondeig simultanis.

Neteja sense amagar errors

La neteja ha d'executar-se després de capturar les evidències. En cas d'èxit, elimina els missatges o deixa que una retenció curta els gestioni. En cas d'error, conserva l'adreça i l'ID del missatge en artefactes protegits del CI prou temps per a la investigació, i després elimina'ls.

Mai imprimeixis codis de verificació, enllaços privats o cossos HTML complets en els registres de compilació públics.

Fes que els reintents siguin idempotents

Reintenta la prova com una nova execució amb una adreça nova. No assumeixis que repetir la mateixa sol·licitud contra el mateix compte i bústia comença des d'un estat net. L'emissor pot invalidar codis antics, limitar les sol·licituds repetides o rebutjar invitacions duplicades.

Si una sol·licitud de xarxa supera el temps d'espera, distingeix entre «no s'ha rebut resposta» i «l'operació no s'ha produït». Comprova l'estat observable abans d'emetre un reintent destructiu.

Informa del punt de fallada

Un error d'automatització útil identifica una d'aquestes etapes:

  1. la generació de l'adreça ha fallat;
  2. l'acció del producte ha fallat abans d'enviar el correu electrònic a la cua;
  3. no ha arribat cap missatge coincident abans del termini;
  4. el missatge ha arribat però el contingut no coincideix;
  5. l'acció de verificació ha fallat;
  6. la neteja ha fallat.

Aquesta classificació transforma un «test de correu electrònic ha fallat» intermitent en una tasca que un equip pot assumir.

Per a la matriu de proves més àmplia, llegeix Un pla real de proves de correu electrònic. Per al diagnòstic de l'entrega, utilitza El correu de verificació no arriba: Troba l'etapa trencada.

GPTMail