Key Takeaways

  • Go is the right language for high-throughput email verification because goroutines and channels make worker pools trivial to implement.
  • The pattern is a job channel feeding N workers calling the v2 verify endpoint concurrently, with results streaming to an output channel.
  • Production deployments need three additions: context cancellation, retry with exponential backoff, and rate limiting that respects the API quota.
  • A 16-worker pool processes roughly 100,000 addresses in 8 to 12 minutes against the v2 endpoint, well within rate limits.

Go is the language of choice for any email verification workload that needs to process more than a few thousand addresses. Goroutines and channels collapse the complexity of concurrent HTTP calls into a few dozen lines of code, and the standard library handles everything else: context cancellation, timeouts, JSON parsing, and graceful shutdown. This guide walks through the production pattern that takes a list of email addresses and returns verification results through the v2 API at full network throughput.

The complete reference implementation is documented on the verify email with Go integration page, including framework-specific patterns for net/http, fasthttp, and the Go standard library client.

The v2 Endpoint

Before writing Go, confirm the endpoint works against a known address. The v2 verify endpoint accepts the email as a query parameter and returns a JSON document with all the fields needed for decision logic.

curl -X GET 
  "https://emailverifierapi.com/v2/verify?api_key=YOUR_API_KEY&email=jane@example.com"

# Response
{
  "email": "jane@example.com",
  "status": "passed",
  "sub_status": "mailboxExists",
  "isDisposable": false,
  "isFreeService": false,
  "isOffensive": false,
  "isRoleAccount": false,
  "isGibberish": false,
  "smtp_check": "success"
}

The status field is the primary decision input. Passed indicates the mailbox exists and accepts mail. Failed means the mailbox does not exist, syntax is invalid, or the domain has no MX server. Unknown covers greylisting and transient SMTP errors. The boolean flags surface category-specific risk signals that warrant separate handling.

The Verification Client

The Verifier struct wraps an http.Client with a timeout, the API key, and the base URL. A single instance is safe for concurrent use across goroutines because http.Client is internally synchronized.

// verifier.go
package verifier

import (
    "context"
    "encoding/json"
    "fmt"
    "net/http"
    "net/url"
    "time"
)

type Result struct {
    Email         string `json:"email"`
    Status        string `json:"status"`
    SubStatus     string `json:"sub_status"`
    IsDisposable  bool   `json:"isDisposable"`
    IsFreeService bool   `json:"isFreeService"`
    IsRoleAccount bool   `json:"isRoleAccount"`
    IsGibberish   bool   `json:"isGibberish"`
    SMTPCheck     string `json:"smtp_check"`
}

type Verifier struct {
    apiKey  string
    baseURL string
    client  *http.Client
}

func New(apiKey string) *Verifier {
    return &Verifier{
        apiKey:  apiKey,
        baseURL: "https://emailverifierapi.com/v2/verify",
        client:  &http.Client{Timeout: 10 * time.Second},
    }
}

func (v *Verifier) Verify(ctx context.Context, email string) (*Result, error) {
    q := url.Values{}
    q.Set("api_key", v.apiKey)
    q.Set("email", email)

    req, err := http.NewRequestWithContext(ctx, "GET",
        v.baseURL+"?"+q.Encode(), nil)
    if err != nil {
        return nil, err
    }

    resp, err := v.client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    if resp.StatusCode != 200 {
        return nil, fmt.Errorf("api returned %d", resp.StatusCode)
    }

    var r Result
    if err := json.NewDecoder(resp.Body).Decode(&r); err != nil {
        return nil, err
    }
    return &r, nil
}

Two design choices deserve attention. The Verify method takes a context.Context as its first parameter, which is idiomatic Go for cancellable operations. Callers can cancel the request through context cancellation, which propagates to the HTTP client and aborts the in-flight call. The http.Client has a hard 10-second timeout independent of context, which protects against deadlocked requests when callers pass a non-cancelling context.

Pro Tip Reuse a single http.Client across all goroutines. Creating a new client per call leaks connections and breaks keepalive. The standard library client is concurrent-safe and pools connections automatically.

The Concurrent Worker Pool

For bulk verification, fan out the work across N goroutines pulling from a job channel. Each worker calls Verify concurrently and writes results to an output channel. The pattern handles 100,000 addresses in 8 to 12 minutes with 16 workers, comfortably within the v2 endpoint rate limits.

// pool.go
package verifier

import (
    "context"
    "log"
    "sync"
    "time"
)

type Job struct {
    Email string
}

type Outcome struct {
    Email  string
    Result *Result
    Err    error
}

func (v *Verifier) Pool(
    ctx context.Context,
    workers int,
    jobs <-chan Job,
) <-chan Outcome {
    out := make(chan Outcome, workers*2)

    var wg sync.WaitGroup
    for i := 0; i < workers; i++ {
        wg.Add(1)
        go func(workerID int) {
            defer wg.Done()
            for j := range jobs {
                outcome := v.verifyWithRetry(ctx, j.Email, 3)
                select {
                case out <- outcome:
                case <-ctx.Done():
                    return
                }
            }
        }(i)
    }

    go func() {
        wg.Wait()
        close(out)
    }()

    return out
}

func (v *Verifier) verifyWithRetry(
    ctx context.Context, email string, attempts int,
) Outcome {
    backoff := 200 * time.Millisecond
    var lastErr error

    for i := 0; i < attempts; i++ {
        r, err := v.Verify(ctx, email)
        if err == nil {
            return Outcome{Email: email, Result: r}
        }
        lastErr = err

        if ctx.Err() != nil {
            return Outcome{Email: email, Err: ctx.Err()}
        }

        select {
        case <-time.After(backoff):
            backoff *= 2
        case <-ctx.Done():
            return Outcome{Email: email, Err: ctx.Err()}
        }
    }
    log.Printf("verify failed after %d attempts: %v", attempts, lastErr)
    return Outcome{Email: email, Err: lastErr}
}

The Pool method spawns N worker goroutines and returns an output channel that closes when all workers have finished. The verifyWithRetry helper handles transient network errors with exponential backoff and respects context cancellation throughout. Callers feed jobs into the input channel, range over the output channel, and the pool handles the rest.

100,000 addresses verified in 8-12 minutes with 16 concurrent workers. Source: v2 API throughput benchmarks, 2025

Driving the Pool From a CSV File

The main function ties together input reading, the worker pool, and output writing. Read addresses from a CSV, push them into the job channel, range over outcomes as they arrive, and write each one to the output CSV.

// main.go
package main

import (
    "context"
    "encoding/csv"
    "log"
    "os"
    "os/signal"
    "syscall"

    "yourapp/verifier"
)

func main() {
    apiKey := os.Getenv("EMAILVERIFIER_API_KEY")
    if apiKey == "" {
        log.Fatal("EMAILVERIFIER_API_KEY required")
    }

    ctx, cancel := signal.NotifyContext(
        context.Background(),
        syscall.SIGINT, syscall.SIGTERM,
    )
    defer cancel()

    in, err := os.Open("input.csv")
    if err != nil {
        log.Fatal(err)
    }
    defer in.Close()

    out, err := os.Create("output.csv")
    if err != nil {
        log.Fatal(err)
    }
    defer out.Close()

    w := csv.NewWriter(out)
    defer w.Flush()
    w.Write([]string{"email", "status", "sub_status", "is_disposable"})

    v := verifier.New(apiKey)
    jobs := make(chan verifier.Job, 256)
    outcomes := v.Pool(ctx, 16, jobs)

    go func() {
        defer close(jobs)
        r := csv.NewReader(in)
        r.Read() // skip header
        for {
            row, err := r.Read()
            if err != nil {
                return
            }
            jobs <- verifier.Job{Email: row[0]}
        }
    }()

    for o := range outcomes {
        if o.Err != nil {
            w.Write([]string{o.Email, "error", o.Err.Error(), ""})
            continue
        }
        w.Write([]string{
            o.Result.Email,
            o.Result.Status,
            o.Result.SubStatus,
            boolStr(o.Result.IsDisposable),
        })
    }
}

func boolStr(b bool) string {
    if b { return "true" }
    return "false"
}

The signal.NotifyContext call propagates SIGINT and SIGTERM into the context, which means Ctrl+C cleanly cancels in-flight verifications and flushes the output CSV before exiting. This matters for long-running bulk jobs because partial results stay on disk even when the operator interrupts the run.

For broader integration patterns across other languages, the email verification integrations hub covers Node.js, Python, Ruby, Java, PHP, and the rest of the supported stacks. New developers can grab 100 free email verification credits on signup to test the integration before committing to a plan.

Frequently Asked Questions

How many concurrent workers should I run?

Sixteen is a good default for bulk verification. The v2 endpoint handles concurrency comfortably and the network is rarely the bottleneck. Increasing beyond 32 workers tends to surface API rate limits without measurable throughput improvement.

What about HTTP/2 connection multiplexing?

Go's net/http client uses HTTP/2 automatically when the server supports it. Verification calls share connections through the pool, so explicit HTTP/2 configuration is not required. The default behavior is correct.

How do I avoid double-counting on retries?

Verification calls are idempotent at the application layer. The same email returns the same result within the cache TTL, and retries on transient errors do not double-charge against the API quota because the underlying call only counts on successful completion.

Can I use this pattern for real-time signup verification?

Yes. For real-time use, skip the worker pool and call Verify directly from the request handler. Wrap the verifier in middleware similar to net/http handlers and the same retry and timeout behavior applies.