Email Testing in CI/CD (GitHub Actions)

Email tests that pass locally often flake in CI — slower delivery, shared mailboxes, leaked credentials. Running them in GitHub Actions cleanly comes down to three things: a secret for the API key, an ephemeral inbox per run, and tight timeouts. Part of email testing for developers.

1. Store the API key as a secret

Never hard-code the inbox API key. Add it under repo Settings → Secrets and variables → Actions, then expose it as an env var to the test step. The disposable email API authenticates with that key.

2. A minimal workflow

# .github/workflows/e2e.yml
name: e2e
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright test
        env:
          MAIL_KEY: ${{ secrets.MAIL_KEY }}

3. An inbox per PR run

Create a fresh inbox inside the test (one per test, ideally) so parallel jobs and reruns never collide, and let it expire on its own — no cleanup step needed. This "ephemeral inbox per run" pattern is what keeps CI email checks deterministic.

4. Keep timeouts tight

Transactional email in a test environment should arrive in under five seconds; a 20–30s polling ceiling catches real failures fast instead of hanging the job. Better still, use a webhook so the test resolves the instant mail lands.

Get started

Add the secret, drop in the workflow, and wire the inbox calls from your Playwright, Node or Python suite. Read the OpenAPI docs to begin.