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

# API Reference

> How to use the Connecta DESK API reference: base URL, playground, versioning and the map of the 17 modules.

This section documents the 150 v1 endpoints, generated from the API's OpenAPI specification. Each
page shows the accepted parameters, the request body, the response format and a playground where
you can try the call right in your browser.

## Base URL

```bash theme={null}
https://api.connectadesk.com/api/v1
```

On-premise installations use their own environment's domain, followed by `/api/v1`.

<Note>
  Creating, editing, rotating and revoking tokens is not part of the API. For security reasons,
  these operations can only be done in the panel.
</Note>

## Testing from the playground

<Steps>
  <Step title="Open any endpoint">
    Start with a `GET`, such as `GET /contacts`. Reads don't change any data.
  </Step>

  <Step title="Provide the token">
    In the **Authorization** field, paste your `sk_live_…` key. It is stored only in your
    browser.
  </Step>

  <Step title="Check the server">
    The playground points to `https://api.connectadesk.com/api/v1`. If your installation is
    on-premise, replace it with your environment's domain.
  </Step>
</Steps>

<Warning>
  The playground makes **real** calls. A `DELETE` run here actually deletes the record, without
  asking for confirmation and with no way to undo it. While you are exploring, use staging data.
</Warning>

## The map of the modules

Each group in the left-hand menu matches a token permission module. If an endpoint responds with
`403 ERR_API_FORBIDDEN_SCOPE`, your token is missing the permission for that group's module.

<Columns cols={2}>
  <Card title="Conversations" icon="message-square">
    Contacts, Tickets, Messages, Channels and Webchat. This is the foundation for anyone
    integrating customer service.
  </Card>

  <Card title="Organization" icon="list">
    Tags, Queues, Wrap-up types, Users and Permission profiles. They define how tickets are
    distributed and classified, and what each person can do.
  </Card>

  <Card title="Outreach" icon="megaphone">
    Scheduled messages, Quick replies and Campaigns. They cover the messages that go from the
    company to the customer.
  </Card>

  <Card title="Sales" icon="kanban">
    CRM, Products and Custom fields. They support the sales boards and the catalog.
  </Card>

  <Card title="Reports" icon="chart-column">
    Conversation and automation reports, plus the dashboard indicators. They show the numbers of
    the operation.
  </Card>
</Columns>

## Conventions

A few rules apply to every endpoint:

<CardGroup cols={2}>
  <Card title="Envelope" icon="box" href="/en/essentials/requisicoes-e-respostas">
    Every resource comes in `data`, and every error comes in `error`.
  </Card>

  <Card title="Pagination" icon="list" href="/en/essentials/paginacao">
    `page` and `perPage`, with `hasMore` to tell you whether there are more pages. There is no
    `total`.
  </Card>

  <Card title="Idempotency" icon="repeat" href="/en/essentials/idempotencia">
    `Idempotency-Key` on `POST` and `PUT`.
  </Card>

  <Card title="Limits" icon="gauge" href="/en/essentials/limites-de-uso">
    Request limit per minute, per company.
  </Card>
</CardGroup>

## Versioning

The version is part of the path: `/api/v1`. While it exists, changes will only be **additive**.
New fields and endpoints may appear, but the ones that already exist keep their name, type and
meaning.

That is why your integration should ignore fields it doesn't recognize instead of failing when it
finds them. Changes that break compatibility only come with a new version in the path.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.