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

# Quickstart

> Implement one endpoint, serve the standard envelope, and see exactly what HunterAI sends and expects back.

This page builds the smallest possible conformant endpoint — `GET /pipelines` — so you
can see the request HunterAI sends and the response it expects. Every other endpoint
follows the same envelope and paging rules.

## 1. Pick a base URL

Host your API under a stable, versioned root. HunterAI stores it verbatim (a trailing
slash is stripped) and prepends it to every endpoint path.

```
https://crm.example.uz/api/hunterai/v1
```

With that base URL, HunterAI calls `https://crm.example.uz/api/hunterai/v1/pipelines`,
`.../contacts`, and so on.

## 2. Require a Bearer token

Every request arrives with two headers:

```http theme={null}
Authorization: Bearer <the token you issued to HunterAI>
Accept: application/json
```

Reject anything else with [`401`](/errors). See [Authentication](/authentication) for
how the token is issued, stored, and rotated.

## 3. Serve the envelope

Return records under `data`, and set `has_more` to tell HunterAI whether to request the
next page. HunterAI sends `page` (1-based) and `limit` (always `100`).

<CodeGroup>
  ```http Request theme={null}
  GET /api/hunterai/v1/pipelines?limit=100&page=1 HTTP/1.1
  Host: crm.example.uz
  Authorization: Bearer sk_live_9f2c…
  Accept: application/json
  ```

  ```json Response — 200 OK theme={null}
  {
    "data": [
      {
        "id": "pipe-sales",
        "name": "Sotuv",
        "is_archived": false,
        "sort": 1,
        "stages": [
          { "id": "stg-new",  "name": "Yangi",      "kind": "open", "sort": 1, "color": "#4A90D9" },
          { "id": "stg-nego", "name": "Muzokara",   "kind": "open", "sort": 2, "color": "#F5A623" },
          { "id": "stg-won",  "name": "Muvaffaqiyat","kind": "won",  "sort": 3, "color": "#2FBF71" },
          { "id": "stg-lost", "name": "Yo'qotilgan", "kind": "lost", "sort": 4, "color": "#D0021B" }
        ]
      }
    ],
    "has_more": false
  }
  ```
</CodeGroup>

<Check>
  `has_more: false` ends paging. HunterAI stops when `has_more` is falsy — **not** when
  `data` is empty. If you return `has_more: true` forever, the sync trips a safety limit
  and fails. See [How sync works](/concepts/how-sync-works#paging).
</Check>

## 4. Test the connection

Once your `/pipelines` endpoint is live and the token works, your HunterAI business owner
runs the built-in test call. It fetches the first page of `/pipelines` and reports
whether the API was reachable, whether the token authenticated, and how many pipelines
came back.

```json Test-connection result theme={null}
{
  "reachable": true,
  "authenticated": true,
  "detail": "Connection successful.",
  "pipelines_found": 1
}
```

## 5. Add the rest

`/pipelines` uses the simplest profile (no filter, full list every time). The four
collection endpoints — `/contacts`, `/leads`, `/tasks`, `/calls`, `/events` — additionally
receive an [`updated_since`](/concepts/how-sync-works#incremental-sync) filter and must
return records ordered by `updated_at` ascending.

<Steps>
  <Step title="Required">
    [`/users`](/endpoints/users), [`/contacts`](/endpoints/contacts), and
    [`/leads`](/endpoints/leads). A missing required endpoint fails that entity.
  </Step>

  <Step title="Optional">
    [`/events`](/endpoints/events), [`/tasks`](/endpoints/tasks), and
    [`/calls`](/endpoints/calls). Return `404` for any you do not implement — the sync
    skips it and still succeeds.
  </Step>

  <Step title="Pre-flight">
    Run through the [Conformance checklist](/guides/conformance-checklist) before you
    request a connection.
  </Step>
</Steps>