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

# Getting Started with KYT

> Run your first wallet or transaction check in the Dataspike dashboard, or integrate KYT into your product with a first API call.

You can use KYT in two ways: interactively in the **dashboard** (great for compliance teams and manual reviews) or through the **REST API** (for automated screening inside your product). Both run the same checks and produce the same reports.

***

## In the dashboard

<Steps>
  <Step title="Open the KYT module">
    Log in at `dash.dataspike.io`, click the grid icon next to the module name in the top-left corner, and select **KYT** from the dropdown. You land on the **Wallet Scoring** page — the main interface for running checks.
  </Step>

  <Step title="Run a check">
    Select the **Network** (Ethereum, Bitcoin, or TRON) and the **Token** — leave it empty for the native asset (ETH/BTC/TRX) or choose USDT/USDC. Paste a **wallet address** or a **transaction TxID** into the input field and click **Scan**. Results are processed in seconds and saved to your history.
  </Step>

  <Step title="Read the result">
    Every scan is saved to the **Recently verified wallets** table. Each row shows the wallet/TxID, date, check type, network, token, the risk score with a Low/Moderate/High badge, and **Flags** — the top risk categories detected. Open a row for the full breakdown, or see [How to read a KYT report](wallet-checks-kyt/how-to-read-a-kyt-report).
  </Step>

  <Step title="Download the PDF report">
    Click the download icon at the end of any row to save a full AML PDF report — including the risk score, category breakdown, and direct transfers list — for your audit trail.
  </Step>
</Steps>

***

## Your first API call

<Steps>
  <Step title="Get your API key">
    In `dash.dataspike.io`, go to **API → API Settings** and click **Generate**. Store the key securely.

    <Warning>
      Never expose the API key in frontend or mobile code. Always proxy KYT requests through your backend.
    </Warning>
  </Step>

  <Step title="Submit an address check">
    ```bash theme={null}
    curl -X PUT "https://api.dataspike.io/api/v4/kyt/checks/address" \
      --header "ds-api-token: YOUR_API_KEY" \
      --header "Content-Type: application/json" \
      --data '{
        "blockchain": "eth",
        "address": "0x029Ec4db927f58cfBf25FA45AbBd0777d791e3bb",
        "token": "",
        "directs": false
      }'
    ```

    Every request needs the `ds-api-token` header and `Content-Type: application/json`. Use `btc`, `eth`, or `trx` for `blockchain`, and leave `token` empty for the native asset. Store the returned check `id` — you need it to fetch the result and the report.
  </Step>

  <Step title="Poll for the result">
    ```bash theme={null}
    curl -X GET "https://api.dataspike.io/api/v4/kyt/checks/address/YOUR_CHECK_ID" \
      --header "ds-api-token: YOUR_API_KEY"
    ```

    Analysis typically completes in under 5 seconds. While it is still in progress, the API returns `404` with `"No data, please try again later"` — this is normal. Retry after 2–5 seconds with exponential backoff until `status` is `"success"`.
  </Step>

  <Step title="Act on the risk grade">
    Branch your logic on `risk_score_grade`:

    * `low` → auto-approve
    * `moderate` → queue for manual review / enhanced due diligence
    * `high` → block and escalate

    See [Risk scoring](/kyt/risk-scoring) for what each grade means — and note that the raw `risk_score` is a **0–1 coefficient**, not a percentage.
  </Step>

  <Step title="Download and archive the PDF report">
    ```bash theme={null}
    curl -X GET "https://api.dataspike.io/api/v4/kyt/checks/address/YOUR_CHECK_ID/report" \
      --header "ds-api-token: YOUR_API_KEY"
    ```

    Store the report with your customer or transaction record as evidence of the automated risk assessment.
  </Step>
</Steps>

***

## Recommended integration pattern

1. On user deposit or wallet connect → submit an address check (`PUT /api/v4/kyt/checks/address`).
2. Store the returned check `id` alongside the user or transaction record in your database.
3. Poll `GET /api/v4/kyt/checks/address/{id}` until `status = "success"`.
4. Branch on `risk_score_grade`: `low` → auto-approve, `moderate` → queue for review, `high` → block and alert.
5. Download and store the PDF report linked to the check `id` for your audit trail.

For screening individual deposits or withdrawals, use a transaction check; for isolating one sender → recipient flow (especially on Bitcoin), use a transfer check. See [How KYT works](/wallet-checks-kyt/how-kyt-works#the-three-check-types).

***

## Rate limits

The KYT API enforces a limit of **24 requests per second per API key**. Requests above the threshold receive `429 Too Many Requests` with a `Retry-After` header. Use exponential backoff starting at 1 second. For bulk screening, process in batches of 20 with a 1-second pause between batches. For very high volumes, contact `service@dataspike.io` to discuss increased limits.

***

## Common response codes

| Code  | Meaning                                                                                                                                                                                                    |
| ----- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `400` | Invalid parameters or missing required field.                                                                                                                                                              |
| `401` | Missing or invalid `ds-api-token` header.                                                                                                                                                                  |
| `403` | Expired license or insufficient check balance.                                                                                                                                                             |
| `404` | Address/TX not found on the blockchain, check `id` does not exist, the address has no transaction history, **or the analysis is still in progress** (`"No data, please try again later"` — retry shortly). |
| `422` | Valid JSON but semantically incorrect values.                                                                                                                                                              |
| `429` | Rate limit exceeded; honor `Retry-After`.                                                                                                                                                                  |

The full field mapping, response schemas, and status codes live in the [Result fields reference](/wallet-checks-kyt/result-fields-coverage).