> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://documentation.apexverify.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://documentation.apexverify.com/_mcp/server.

# Support

Need help? The ApexVerify team is here. Find the right channel below — whether you have a billing question, a technical integration issue, or just want to report a bug.

---

## Contact

#### [Email Support](mailto:contact@apexverify.com)

Reach the team directly at **[contact@apexverify.com](mailto:contact@apexverify.com)**. Include your `batch_uuid` or account ID when reporting API issues to speed up the investigation.

#### [Dashboard](https://app.apexverify.com)

Manage batches, monitor credit usage, rotate API keys, and access usage logs — all from the web dashboard.

#### [Website Chatbot](https://apexverify.com)

Chat with us directly on our website. Our chatbot is available 24/7 to answer common questions and connect you with the team.

#### [API Status](https://status.apexverify.com)

Check real-time API availability and subscribe to incident notifications for your region.

**Response times:** We aim to respond to all support emails within 1 business day. For production-impacting issues, please include "URGENT" in the subject line to escalate priority handling.

---

## Frequently Asked Questions

#### What types of data can ApexVerify verify?

ApexVerify verifies two types of contact data:

* **Email addresses** — We run syntax validation, domain/MX record checks, SMTP probing, and flag disposable, role-based, free-provider, and catch-all addresses.
* **Phone numbers** — We identify number type (mobile, landline, VoIP, toll-free, etc.), check live network status, detect porting, and identify the current operator via HLR lookup.

Both modes are available for batch processing (file upload) and real-time unit verification (single record via API).

#### How are credits consumed?

Credits are consumed per verified record:

* **1 email credit** per email address verified
* **1 phone credit** per phone number verified

Credits are deducted at the time verification launches, not at upload. If a batch uses cached results (account cache or global cache), you receive a **50% credit refund** for those cache-hit records.

Check your current balance at any time with `GET /v1/account/credits`.

#### What is the difference between account cache and global cache?

Both caches reduce cost on repeat verifications by reusing prior results:

| Cache             | What it uses                         | Credit refund | Privacy                           |
| :---------------- | :----------------------------------- | :------------ | :-------------------------------- |
| **Account cache** | Your own previous results            | 50%           | Private — only your data          |
| **Global cache**  | Anonymized results from all accounts | 50%           | Fully anonymized — no PII exposed |

You can configure `use_account_cache` and `use_global_cache` on each batch via `PUT /v1/batch/{uuid}`. Both are **enabled by default** and checked in order: account cache first, then global cache. You can also set `max_account_cache_backoff` and `max_global_cache_backoff` (1–180 days) to control how far back the system looks.

#### What file format does the batch upload accept?

Batch uploads accept a plain `.TXT` file with **one email or phone number per line**, UTF-8 encoded. No headers, no commas, no CSV — just raw values.

Example for email:

```
alice@example.com
bob@company.org
carol@domain.net
```

Example for phone (E.164 format recommended):

```
+447891234567
+447911123456
+441255512349
```

The file is uploaded via `POST /v1/batch` as `multipart/form-data`. Maximum file size and row limits are shown in the dashboard.

#### How do I re-run parsing if I change parameters?

Parsing and parameter configuration are intentionally decoupled so you can iterate freely:

1. Update parameters at any time using `PUT /v1/batch/{uuid}`
2. Trigger a re-parse by calling `PATCH /v1/batch/{uuid}` again

You can repeat this cycle as many times as needed — there is no limit on re-parses before a batch is launched. The `PATCH` endpoint is idempotent and safe to call multiple times. See the [API Verification Workflow](/tutorials/api-verification-workflow) guide for the full step-by-step.

#### What does each batch status mean?

Batch status is returned by `GET /v1/batch/{uuid}` and `GET /v1/batch/{uuid}/details`. Here are all possible values:

| Status                   | Meaning                                  | Next action                              |
| :----------------------- | :--------------------------------------- | :--------------------------------------- |
| `parsing_content`        | File is being parsed and prepared        | Wait — poll again in a few seconds       |
| `internal_error`         | A system error occurred during parsing   | Contact support with the `batch_uuid`    |
| `ready_for_verification` | Batch is parsed and ready to launch      | Call `POST /v1/batch/{uuid}` to start    |
| `verification_ongoing`   | Verification is running                  | Poll `GET /v1/batch/{uuid}` until done   |
| `verification_done`      | Verification complete, results available | Export via `GET /v1/batch/{uuid}/export` |

#### How do I export results after verification?

Once a batch reaches `verification_done`, call:

```http
GET /v1/batch/{batch_uuid}/export?format=xlsx
GET /v1/batch/{batch_uuid}/export?format=json
```

* **`xlsx`** — Returns a binary Excel file, matching the layout from the web dashboard. Download with `curl -o results.xlsx`.
* **`json`** — Returns a JSON object keyed by email/phone, each with full result fields (`valid`, `wrong`, `quality`, `is_disposable`, etc.).

You can also include `include_details=true` and `include_statistics=true` in the query string (both default to `true`) to control what sections appear in the JSON export.