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

# Testing & Environments

> How to test your Authmatech integration safely: the sandbox, balance and product enablement, the consistent response envelope, and a pre-launch checklist.

This guide covers how to build and test an Authmatech integration with confidence before you send production traffic.

## Base URL

All requests go to a single base URL over HTTPS:

```
https://service.authmatech.com
```

Plain HTTP is not supported.

## Sandbox

Authmatech provides a sandbox so you can develop and test without affecting production data or consuming live balance. Provision sandbox credentials from the [dashboard](https://dashboard.authmatech.com) and use them exactly as you would production credentials — the `X-API-KEY` and `X-CLIENT-ID` headers and request shapes are identical.

<Tip>
  Keep sandbox and production credentials in separate environment variables, and make the base URL and credentials configurable per environment so promoting to production is a config change, not a code change.
</Tip>

## Testing the response envelope

Every response — success or failure — uses the same envelope, so write your client to read it consistently:

```json theme={null}
{
  "success": true,
  "messages": [
    { "type": "SUCCESS", "code": null, "message": null, "httpStatus": "OK", "technical": false, "arguments": null }
  ],
  "data": { "validNumber": true }
}
```

* Branch business logic on `data` (e.g. `data.validNumber`, `data.decision`).
* Treat `success: false` and non‑`200` status codes as errors, and surface `messages[].message`.

A verification that returns `validNumber: false` is a **successful call with a negative verdict** — make sure your tests distinguish that from an actual error.

## Things to verify before launch

<Steps>
  <Step title="Credentials & headers">
    Both `X-API-KEY` and `X-CLIENT-ID` are sent on every request, and the API key is only ever used server-side.
  </Step>

  <Step title="Product enablement">
    The products you call (Verify, Trust, Shield, Detect, …) are enabled for your account. A disabled product returns `400`. Check `GET /v1/api/me/products`.
  </Step>

  <Step title="Balance">
    Your account has sufficient, non-expired balance. Verification and intelligence calls consume balance; an expired or empty balance returns `400`.
  </Step>

  <Step title="Fallback path">
    Your client handles the no-mobile-data case (Wi‑Fi/VPN) with a fallback — manual entry or retry on mobile data — rather than failing the journey.
  </Step>

  <Step title="Error handling">
    You handle `401`, `400`, and `500` distinctly and retry only the retryable ones with backoff. See [Errors](/errors).
  </Step>
</Steps>

## Monitoring your usage

While testing and after launch, the Client Portal endpoints give you visibility:

* `GET /v1/api/me/usage` — usage analytics.
* `GET /v1/api/me/verifications` — verification history.
* `GET /v1/api/me/balance-history` — balance movements over time.

## Next steps

<CardGroup cols={2}>
  <Card title="Errors & responses" icon="triangle-exclamation" href="/errors">
    The response envelope and every status code.
  </Card>

  <Card title="Rate limits" icon="gauge" href="/api/rate-limits">
    Limits and retry guidance.
  </Card>
</CardGroup>