> ## Documentation Index
> Fetch the complete documentation index at: https://docs.boltroute.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Verify emails with Bolt Route's API before you send.

## Why you are here

You want to stop bad addresses before they hit your ESP, protect sender reputation, and keep acquisition lists clean. The Bolt Route Email Verification API lets you validate a single address at signup or run large list checks in the background without building a full pipeline yourself.

## What you can do

<CardGroup cols={2}>
  <Card title="Verify one address" icon="bolt" href="/api-reference/endpoints/realtime-verification" cta="Realtime verification">
    Check deliverability signals on a single email in real time.
  </Card>

  <Card title="Verify a list" icon="list-check" href="/api-reference/endpoints/batch-verification/create-task" cta="Create batch task">
    Submit a list and download results when processing completes.
  </Card>

  <Card title="Upload a file" icon="file-arrow-up" href="/api-reference/endpoints/file-upload/upload-file" cta="Upload CSV/XLSX">
    Send a file and let the system handle parsing and validation.
  </Card>

  <Card title="Track usage" icon="chart-simple" href="/api-reference/endpoints/metrics-controller" cta="View metrics">
    Pull verification metrics and monitor usage over time.
  </Card>
</CardGroup>

## How it works (quick flow)

1. Create an API key.
2. Pick realtime for one-off checks or batch for large lists.
3. Read the verification result and take action in your app.

## Base URL and versioning

All endpoints live under `/api/v1`. Examples use `https://api.boltroute.ai` as a placeholder, so replace it with your production or staging base URL.

## Authentication

Every request requires your API key. Send it with the `Authorization: Bearer <api_key>` header. See [Authorization](/api-reference/authorization) for details.

## Understanding results

You get an overall `status` plus supporting signals (for example `is_disposable`, `is_role_based`, `is_catchall`, and DNS/SMTP checks). Treat `valid` as deliverable, `invalid` as a hard fail, `invalid_syntax` as invalid input, `disposable_domain` as disposable, and `unknown` or `catchall` as cases that need your business logic.