> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nekt.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Zenvia Voice as a data source
> Bring data from Zenvia Voice to Nekt.
Zenvia Voice (formerly TotalVoice) is a Brazilian voice/telephony API platform for making and receiving phone calls, conferences, and running a basic PBX (extensions, queues, IVR). This connector uses the **Zenvia Voice API** (`voice-api.zenvia.com`) with a static account token to extract your call detail records, conference records, extension roster, DID (virtual number) inventory, and registered caller IDs (bina).
This connector targets the **Voice** product specifically. It is a different product, base URL, and authentication header than the general Zenvia messaging/CPaaS API (SMS, WhatsApp, RCS, Email).
## Configuring Zenvia Voice as a Source
In the [Sources](https://app.nekt.ai/sources) tab, click on the "Add source" button located on the top right of your screen. Then, select the Zenvia Voice option from the list of connectors.
Click **Next** and you'll be prompted to add your access.
### 1. Add account access
Authentication uses a static **Access Token** generated for your Zenvia Voice account.
Go to `https://voice-app.zenvia.com/painel/login.php` and log in to your account.
On the lower-left corner of the dashboard, click the copy icon next to **Access Token**.
Paste the token into the **Access Token** field.
The Access Token grants full access to your Voice account's data. Keep it secret — never share it or commit it to public code.
The following configurations are available:
* **Access Token**: (Required) The static token from the Voice panel described above.
* **Start Date**: (Optional) Lower bound for the `calls`, `conferences`, and `extensions` streams. If omitted, defaults to 90 days before the current date.
Once you're done, click **Next**.
### 2. Select streams
Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.
> Tip: The stream can be found more easily by typing its name.
Select the streams and click **Next**.
### 3. Configure data streams
Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
* **Layer**: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
* **Folder**: a folder can be created inside the selected layer to group all tables being created from this new data source.
* **Table name**: we suggest a name, but feel free to customize it. You have the option to add a **prefix** to all tables at once and make this process faster!
* **Sync Type**: you can choose between INCREMENTAL and FULL\_TABLE.
* Incremental: every time the extraction happens, we'll get only the new data - which is good if, for example, you want to keep every record ever fetched.
* Full table: every time the extraction happens, we'll get the current state of the data - which is good if, for example, you don't want to have deleted data in your catalog.
Once you are done configuring, click **Next**.
### 4. Configure data source
Describe your data source for easy identification within your organization, not exceeding 140 characters.
To define your [Trigger](https://docs.nekt.com/get-started/core-concepts/triggers), consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times).
Optionally, you can define some additional settings:
* Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource [here](https://docs.nekt.com/get-started/core-concepts/resource-control).
* Determine when to execute an **Additional [Full Sync](https://docs.nekt.com/get-started/core-concepts/types-of-sync#additional-full-sync)**. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
Once you are ready, click **Next** to finalize the setup.
### 5. Check your new source
You can view your new source on the [Sources](https://app.nekt.ai/sources) page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.
For you to be able to see it on your [Catalog](https://app.nekt.ai/catalog), you need at least one successful source run.
# Streams and Fields
Below you'll find all available data streams from Zenvia Voice and their corresponding fields.
Call detail records (perna A / perna B) from `/chamada/relatorio`. Incremental sync on `data_criacao`.
**Key Fields:**
| Field | Type | Description |
| :--------------------------------- | :------- | :------------------------------------------- |
| `id` | Integer | Unique identifier for the call (primary key) |
| `data_criacao` | Datetime | When the call was created (replication key) |
| `ativa` | Boolean | Whether the call is still active |
| `url_gravacao` | String | Recording URL, if recorded |
| `cliente_id` | Integer | Client identifier |
| `conta_id` | Integer | Account identifier |
| `ramal_id_origem` | Integer | Originating extension identifier |
| `tags` | String | Free-text tags |
| `status_geral` | String | Overall call status |
| `origem_numero` | String | Origin phone number/extension |
| `origem_tipo` | String | Origin leg type |
| `origem_status` | String | Origin leg status |
| `origem_duracao_segundos` | Integer | Origin leg duration in seconds |
| `origem_duracao_cobrada_segundos` | Integer | Origin leg billed duration in seconds |
| `origem_duracao_falada_segundos` | Integer | Origin leg talk time in seconds |
| `origem_preco` | Number | Origin leg price |
| `origem_bina_origem` | String | Caller ID used for the origin leg |
| `destino_numero` | String | Destination phone number/extension |
| `destino_tipo` | String | Destination leg type |
| `destino_status` | String | Destination leg status |
| `destino_duracao_segundos` | Integer | Destination leg duration in seconds |
| `destino_duracao_cobrada_segundos` | Integer | Destination leg billed duration in seconds |
| `destino_duracao_falada_segundos` | Integer | Destination leg talk time in seconds |
| `destino_preco` | Number | Destination leg price |
| `destino_bina_destino` | String | Caller ID used for the destination leg |
Conference call records from `/conferencia/relatorio`. Incremental sync on `data_criacao`.
**Key Fields:**
| Field | Type | Description |
| :------------------------- | :------- | :--------------------------------------------------------------- |
| `id` | Integer | Conference identifier (part of the primary key — see note below) |
| `numero_destino` | String | Destination phone number |
| `data_criacao` | Datetime | When the conference call was created (replication key) |
| `data_inicio` | Datetime | When the conference call started |
| `tipo` | String | Number type (e.g., fixo) |
| `status` | String | Call status |
| `duracao_segundos` | Integer | Duration in seconds |
| `duracao_cobrada_segundos` | Integer | Billed duration in seconds |
| `duracao_falada_segundos` | Integer | Talk time in seconds |
| `preco` | Number | Price |
| `url_conferencia` | String | Conference recording URL |
| `resposta_usuario` | Boolean | Whether the user responded (DTMF) |
| `resposta` | String | DTMF response captured |
The public API docs' own example response reuses the same `id` across two different conference legs, so `id` alone is not a reliable primary key here. This connector keys on `id` + `data_inicio` + `numero_destino`.
Extension (ramal) roster from `/ramal/relatorio`. Full-table sync — the endpoint requires a date range filtered by extension creation date, but the returned object has no timestamp field, so there is no usable replication key.
**Key Fields:**
| Field | Type | Description |
| :----------------- | :------ | :------------------------------------------------ |
| `id` | Integer | Unique identifier for the extension (primary key) |
| `ramal` | String | Extension number |
| `login` | String | Login email for the extension |
| `bina` | String | Default caller ID for the extension |
| `webphone_key` | String | Webphone access key |
| `ligacao_externa` | Boolean | Whether external calls are allowed |
| `ligacao_celular` | Boolean | Whether mobile calls are allowed |
| `gravar_audio` | Boolean | Whether calls are recorded |
| `acesso_gravacoes` | Boolean | Whether the extension can access recordings |
| `webphone` | Boolean | Whether the webphone is enabled |
| `ura_id` | Integer | Linked IVR (URA) identifier |
| `voicemail` | Boolean | Whether voicemail is enabled |
| `tags` | String | Free-text tags |
Virtual inbound phone number inventory from `/did`. Full-table sync — no query params or pagination.
**Key Fields:**
| Field | Type | Description |
| :------- | :------ | :------------------------------------------ |
| `id` | Integer | Unique identifier for the DID (primary key) |
| `cidade` | String | City associated with the number |
| `estado` | String | State/region associated with the number |
| `numero` | String | Full phone number (E.164) |
Registered caller-ID (bina) numbers from `/bina/relatorio`. Full-table sync.
**Key Fields:**
| Field | Type | Description |
| :---------------- | :------- | :------------------------------------------- |
| `id` | Integer | Unique identifier for the bina (primary key) |
| `numero_telefone` | String | Registered caller-ID phone number |
| `data_criacao` | Datetime | When the bina was registered |
| `fixo` | Boolean | Whether the number is a landline |
| `confirmado` | Boolean | Whether the number is confirmed/validated |
## Implementation Notes
### Sync mode
`Calls` and `Conferences` sync incrementally on `data_criacao`. `Extensions`, `DIDs`, and `Bina` are full-table syncs.
### Pagination
`Calls`, `Conferences`, and `Extensions` page through results with an offset (`posicao`) and page size (`limite`, max 200). The API does not return a total record count, so pagination stops once a page returns fewer records than requested.
### API limitations / undocumented behavior
* The public docs don't show a sample response body for `/bina/relatorio` — the array key is assumed by analogy with the other `/relatorio` endpoints and should be verified against a real account.
* Date format for the `data_inicio`/`data_fim` filters is inconsistent across the docs' own examples (plain date in the `curl` sample vs. full ISO-8601 datetime in the Python client sample); this connector sends full ISO-8601 datetimes.
* Queues (`/fila`) and IVRs (`/ura`) have per-ID report endpoints, but no documented bulk "list all" endpoint to discover IDs from first, so they are not available as streams.
## Skills for agents
Zenvia connector documentation as plain markdown, for use in AI agent contexts.