> ## 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.

# Quickstart: Your First Authmatech Verification in 5 Minutes

> Go from zero to a working Authmatech verification fast. Get your credentials and confirm a mobile identity with a single cURL command — no OTP required.

This guide takes you from a fresh account to your first successful verification. By the end, you will have confirmed a mobile identity through the Authmatech API and seen the response your integration is built on. It takes about five minutes.

<Note>
  Authmatech provides a **sandbox** so you can build and test without affecting production traffic or consuming live balance. See [Testing & environments](/guides/testing) for details.
</Note>

<Steps>
  <Step title="Get your credentials">
    Sign in to the [Authmatech dashboard](https://dashboard.authmatech.com). Generate your API key and copy two values:

    * **Client ID** — sent as the `X-CLIENT-ID` header on every request.
    * **API key** — sent as the `X-API-KEY` header on every request.

    <Warning>
      Your API key grants full server-side access to your account. Never commit it to source control, expose it in browser code, or paste it into public forums. The key is shown **once** at generation — store it in a secrets manager. If it leaks, rotate it immediately from the dashboard.
    </Warning>
  </Step>

  <Step title="Confirm a mobile identity with cURL">
    From your **backend**, run the request below. Replace the credentials and the `mobileNumber`. In a real integration, `encryptedMobileNumber` and `operatorId` come from the Authmatech SDK after the silent check — see [How silent verification works](/concepts/silent-verification).

    ```bash theme={null}
    curl -X POST https://service.authmatech.com/v1/api/verify \
      -H "X-API-KEY: YOUR_API_KEY" \
      -H "X-CLIENT-ID: YOUR_CLIENT_ID" \
      -H "Content-Type: application/json" \
      -d '{
        "mobileNumber": "+962791234567",
        "encryptedMobileNumber": "BASE64_ENCRYPTED_BLOB_FROM_SDK",
        "operatorId": "ZAIN_JO",
        "serviceType": "LOGIN",
        "sdkSessionId": "b1f2c3d4-..."
      }'
    ```

    | Part                    | Description                                                                             |
    | ----------------------- | --------------------------------------------------------------------------------------- |
    | `POST /v1/api/verify`   | The Verify endpoint                                                                     |
    | `X-API-KEY`             | Your server-side API key                                                                |
    | `X-CLIENT-ID`           | Your Client ID                                                                          |
    | `mobileNumber`          | The number the customer claims, in E.164 format                                         |
    | `encryptedMobileNumber` | The encrypted identity code returned by the SDK                                         |
    | `operatorId`            | The mobile operator that confirmed the session                                          |
    | `serviceType`           | The use case: `REGISTRATION`, `LOGIN`, `RESET_PASS`, `UPDATE_DETAILS`, or `TRANSACTION` |
    | `sdkSessionId`          | Optional — links the verification to a stored SDK session for Shield/Detect             |
  </Step>

  <Step title="Read the response">
    A successful request returns HTTP `200 OK`. Authmatech wraps every response in a consistent envelope: a `success` flag, a `messages` array, and a `data` payload.

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

    `data.validNumber` is the verdict: `true` means the customer controls the number they presented. Add `?maskMobile=true` to also receive a masked copy of the confirmed number (e.g. `********67`).

    If something is wrong, `success` is `false` and the `messages` array explains why. The most common first-call issues:

    | Status             | Likely cause                                                                   |
    | ------------------ | ------------------------------------------------------------------------------ |
    | `401 Unauthorized` | Missing or invalid `X-API-KEY` / `X-CLIENT-ID`                                 |
    | `400 Bad Request`  | A required field is missing or the body is malformed                           |
    | `400 Bad Request`  | Insufficient or expired balance, or the product isn't enabled for your account |

    See the [Error reference](/errors) for the full list.
  </Step>
</Steps>

## Add intelligence to the decision

Once a number is verified, enrich the decision using the same session:

<CardGroup cols={2}>
  <Card title="Trust score" icon="gauge-high" href="/guides/trust-shield-detect">
    Turn the signals into a single 0–100 trust score with a recommendation.
  </Card>

  <Card title="Shield assessment" icon="shield" href="/guides/trust-shield-detect">
    Get a real-time risk decision: ALLOW, CHALLENGE, REVIEW, or BLOCK.
  </Card>
</CardGroup>

## What's next?

<CardGroup cols={2}>
  <Card title="Authentication" icon="key" href="/authentication">
    Header details, credential types, and security best practices.
  </Card>

  <Card title="Web SDK" icon="js" href="/sdks/web">
    Run silent verification in the browser, end to end.
  </Card>

  <Card title="Verify guide" icon="circle-check" href="/guides/verify">
    The full server-side verification flow and edge cases.
  </Card>

  <Card title="API reference" icon="code" href="/api/overview">
    Every endpoint with an interactive playground.
  </Card>
</CardGroup>