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

# Pipeimob as a data source

> Bring your Pipeimob sales, brokers and service requests to your Lakehouse.

Pipeimob is a post-sale management platform for real estate agencies and franchise networks: it follows each deal (transação) from the purchase proposal through the CCV (purchase and sale agreement), deed, registry and commission payments. The connector reads your Pipeimob data through the Pipeimob API v2: the transactions, counted by the date the CCV was signed, with their values (VGV and commission), brokers, teams, property, clients and commission charges, plus your users and the service requests (solicitações) of your agencies.

## Configuring Pipeimob 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 Pipeimob option from the list of connectors.

Click **Next** and you'll be prompted to add your access.

### 1. Add account access

The connector uses an **API Key** and an **API Secret** of the Pipeimob API v2. Pipeimob support issues them: open a ticket with Pipeimob asking for API v2 credentials for your agency, allowed to read business data (`negocios.read`). To also sync users and service requests, ask for `usuarios.read` and `solicitacoes.read` too. Nekt uses the credentials only to get the temporary access token that reads your data; it never changes anything in Pipeimob.

<Warning>
  Pipeimob limits each set of credentials to **10 listing requests and 100 single-transaction requests per day** on its business routes, and may temporarily block credentials that go over it. The connector counts its own requests over the last 24 hours and stays under these limits. Notebooks, scripts or other integrations that use the same credentials spend the same allowance, and the connector cannot see them: ask Pipeimob for separate credentials for Nekt, or lower the limits below to leave room for them.
</Warning>

The following configurations are available:

* **API Key**: the API Key of your Pipeimob API v2 credentials. Required.

* **API Secret**: the API Secret of the same credentials. Required.

* **Start Date**: the earliest CCV signing date of the sales to load. It is also the earliest creation date of the service requests. Required. A long history is loaded over several days (see [How transactions are kept up to date](#how-transactions-are-kept-up-to-date)).

* **Reprocess window (days)**: (Default: 30, at most 90) once the history is complete, sales signed in this many recent days are read again on every sync while requests are left. Corrections and cancellations of any sale, recent or old, are picked up from Pipeimob's list of changed transactions.

* **Daily listing request limit**: (Default: 8, at most 10) the most listing requests the connector makes in any 24 hours. Pipeimob allows 10.

* **Daily single-transaction request limit**: (Default: 90, at most 100) the most requests for one specific transaction the connector makes in any 24 hours. Pipeimob allows 100.

* **Listing requests per sync**: (Default: 5) the most listing requests a single sync uses, so syncs close together share the daily limit. With one sync a day, you can raise it up to the daily limit to load the history faster.

* **Single-transaction requests per sync**: (Default: 60) the most single-transaction requests a single sync uses.

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. Users and service requests need the matching permissions on your credentials: if Pipeimob refuses one of them, that table is not changed, the transactions still sync, and the run ends with an error telling you which stream to deselect.

> 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**: use INCREMENTAL for Transactions. It keeps the whole history, updates the transactions that changed, and never creates a second row for the same transaction. Users, Service Requests and Service Request Templates are FULL\_TABLE: each sync reads their current state. Read more about Sync Types [here](https://docs.nekt.com/get-started/core-concepts/types-of-sync).

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/runs/scheduling-and-triggers), consider how often you want data to be extracted from this source. A daily sync is recommended: Pipeimob's request limits are per day, so syncing more often does not bring transactions faster; syncs close together share the same allowance.

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)**. Do not schedule one for Transactions (see the warning in [Data Quality Considerations](#data-quality-considerations)).

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.

<Warning>For you to be able to see it on your [Catalog](https://app.nekt.ai/catalog), you need at least one successful source run.</Warning>

# Streams and Fields

## Available streams

The table below lists every stream, its **slug** (the exact identifier to pass when creating the source via API) and a short description.

| Stream | Slug | Description |
| - | - | - |
| Transactions | `transactions` | Sales and other transactions, read by CCV signing date, with values, brokers, team, property, clients and commission charges. Incremental. |
| Users | `users` | Brokers, managers and other users, active or not. |
| Service Requests | `service_requests` | Requests (solicitações) opened by or to your agencies. |
| Service Request Templates | `service_request_templates` | Templates the requests are opened from, with their target handling time. |

## Fields by stream

Field names follow Pipeimob's own names, without accents. Lists of objects (clients, commission recipients, bank charges, documents, external partners) are JSON strings. Dates of transactions are calendar days in Brasilia time; date-times are in UTC. Fields Pipeimob adds in the future land in `additional_fields` until they get a column of their own.

<Note>
  The broker and team columns of Transactions (`agente_gestor`, `agente_gestor_email`, `lider_equipe`, `agente_gestor_grupo_filial`, `agente_gestor_grupos_a_que_pertence`) always show the **current** registration in Pipeimob: when a broker moves to another team, Pipeimob returns the new team for their past sales too, and a deleted user leaves them empty. `comissionados` is a snapshot recorded on the transaction and does not change afterwards. For production by broker, use `comissionados`. To keep the team at the time of each sale, track these columns with a [History](https://docs.nekt.com/histories/overview) on the Transactions table.
</Note>

<AccordionGroup>
  <Accordion title="Transactions">
    One row per transaction (negócio): every sale with a signed CCV since the Start Date, plus every transaction Pipeimob reported as changed after the source was created (for example a sale cancelled later, whose CCV date was cleared). Counting sales by `data_contrato` in a period gives the sales signed in that period.

    Table: `transactions` · Primary key: `transacao_unique_id_pipeimob` · Sync: Incremental

    | Field | Type | Description |
    | :- | :- | :- |
    | `transacao_unique_id_pipeimob` | String | Unique identifier of the transaction in Pipeimob; the deduplication key. |
    | `imobiliaria` | String | Name of the real estate agency that owns the transaction. |
    | `imobiliaria_unique_id` | String | Unique identifier of the agency that owns the transaction. |
    | `imobiliaria_tipo` | String | Type of the agency (e.g. Franquia). |
    | `codigo_contrato` | String | Contract code of the transaction (sequential code built from the agency prefix). |
    | `codigo_imovel` | String | Code of the property. |
    | `codigo_interno_alternativo` | String | Alternative internal code of the property, when filled in. |
    | `loft_id_listagem` | String | Listing id of the property on Loft, when linked. |
    | `tipo_transacao` | String | Business vertical: lancamento (new development, sold for a builder), terceiros (resale, shown as Venda in Pipeimob) or locacao (rental). |
    | `data_contrato` | Date | CCV signing date (Data de Assinatura do CCV), the date a sale counts by: the field Pipeimob filters with data\_inicio\_ccv and data\_fim\_ccv. Empty while the CCV is not signed, or after the signing was undone (cancelled sale). |
    | `data_contrato_prevista` | Date | Expected CCV signing date. |
    | `data_inicio_venda` | Date | Date the sale (transaction form) was started. |
    | `data_inicio_rascunho_venda` | Date | Date the draft of the sale was started. |
    | `endereco_completo` | String | Full address of the property. |
    | `endereco_logradouro` | String | Street of the property. |
    | `endereco_numero` | String | Street number of the property. |
    | `endereco_complemento` | String | Address complement (apartment, block). |
    | `endereco_bairro` | String | Neighborhood of the property. |
    | `endereco_cidade` | String | City of the property. |
    | `endereco_cep` | String | Postal code (CEP) of the property. |
    | `endereco_uf` | String | State (UF) of the property. |
    | `residencial_comercial` | String | Whether the property is residential or commercial. |
    | `categoria` | String | Category of the property. |
    | `categoria_crm` | String | Category of the property in the CRM. |
    | `area_total` | Number | Total area of the property in square meters. |
    | `area_util` | Number | Usable area of the property in square meters. |
    | `qtd_quartos` | Integer | Number of bedrooms. |
    | `qtd_vagas` | Integer | Number of parking spaces. |
    | `agente_gestor` | String | Managing agent (broker responsible for the transaction). A live reference to the user: it shows the current registration, not the one at the time of the sale. |
    | `agente_gestor_email` | String | E-mail of the managing agent (live reference: the current registration). |
    | `lider_equipe` | String | Team leader of the managing agent (live reference: the current registration, not the one at the time of the sale). |
    | `agente_gestor_grupo_filial` | String | Group or branch the managing agent belongs to today (live reference: when the agent changes team, past sales show the new team). |
    | `agente_gestor_grupos_a_que_pertence` | String (JSON) | Groups the managing agent belongs to today (JSON array; live reference, not the groups at the time of the sale). |
    | `usuarios_participantes` | String (JSON) | Users taking part in the transaction (JSON array of e-mails). |
    | `formulario_tipo` | String | Type of the transaction form. |
    | `valor_contrato` | Number | Contract value of the sale (VGV). |
    | `total_comissao` | Number | Total commission of the transaction (VGC). |
    | `valor_vgc` | Number | VGC of the transaction as Pipeimob computes it (sum of every commission line, including those that do not count as production of their participant), when Pipeimob sends it. |
    | `comissao_quem_paga` | String | Who pays the commission. |
    | `comissao_momento_pagamento` | String | When the commission is paid. |
    | `posse_momento_entrega` | String | When possession of the property is handed over. |
    | `tabela_comissao` | String | Commission table applied to the transaction. |
    | `midia_origem_compradores` | String | Media or lead source of the buyers. |
    | `midia_origem_vendedores` | String | Media or lead source of the sellers. |
    | `etapa_atual` | String | Current stage of the transaction (stage names are configured per agency). |
    | `data_captacao` | Date | Date the property was taken in (captacao). |
    | `data_submissao_proposta` | Date | Date the purchase proposal was submitted. |
    | `diasemestoque` | Integer | Days the property was in stock before the sale. |
    | `financiamento` | Boolean | Whether the purchase is financed. |
    | `financiamento_banco` | String | Bank financing the purchase. |
    | `data_arquivamento` | Date | Date the transaction was archived (finished or cancelled); empty for an active transaction. Archiving can be undone. |
    | `arquivamento_motivo_geral` | String | Reason given when the transaction was archived (e.g. Transacao Finalizada for a completed sale; other reasons such as a cancellation). |
    | `data_registro_publico` | Date | Date of the public registry (Cartorio de Imoveis). |
    | `data_entrega_chaves_posse` | Date | Date the keys or possession were handed over. |
    | `data_titulo_definitivo` | Date | Date of the definitive title (deed or financing contract). |
    | `data_pagamento_comissao_prevista` | Date | Expected commission payment date. |
    | `data_pagamento_comissao` | Date | Commission payment date. |
    | `resumo_comissao_valor_total` | Number | Commission summary: face value of the active commission charges. |
    | `resumo_comissao_valor_recebido` | Number | Commission summary: amount already received. |
    | `resumo_comissao_saldo_a_receber` | Number | Commission summary: amount still to be received. |
    | `resumo_comissao_qtd_parcelas` | Integer | Commission summary: number of installments. |
    | `resumo_comissao_qtd_parcelas_pagas` | Integer | Commission summary: installments paid. |
    | `resumo_comissao_qtd_parcelas_abertas` | Integer | Commission summary: installments still open. |
    | `resumo_comissao_qtd_parcelas_vencidas` | Integer | Commission summary: installments overdue (due before today and unpaid). |
    | `resumo_comissao_proximos_vencimentos` | String (JSON) | Commission summary: due dates of unpaid installments, oldest first, overdue ones included (JSON array of YYYY-MM-DD dates). |
    | `forma_pagamento` | String (JSON) | Payment method of the purchase (JSON array). |
    | `comissionados` | String (JSON) | Commission recipients (broker, agency, franchisor, partners) with participation type and value, as recorded on the transaction: a snapshot that does not change when users change team (JSON array of objects). |
    | `parceiros_externos` | String (JSON) | External partners of the transaction (JSON array of objects). |
    | `cobrancas_bancarias` | String (JSON) | Bank charges of the transaction with status (paga, cancelada, expirada, vencida, pendente) and split (JSON array of objects). |
    | `documentos` | String (JSON) | Documents attached to the transaction (JSON array of objects). |
    | `clientes` | String (JSON) | Clients of the transaction (buyers, sellers) with their participation type (JSON array of objects). |
    | `subetapas` | String (JSON) | Sub-stages of the transaction pipeline (JSON array). |
    | `synced_at` | Datetime | When Nekt last read this transaction from Pipeimob (UTC); the incremental replication key. Its newest value shows how fresh the table is. |
    | `additional_fields` | String (JSON) | Fields Pipeimob returned that have no column of their own, or whose value did not fit it (JSON object). |
  </Accordion>

  <Accordion title="Users">
    Every Pipeimob user your credentials can see (brokers, managers), active or not.

    Table: `users` · Primary key: `uniqueid` · Sync: Full table

    | Field | Type | Description |
    | :- | :- | :- |
    | `uniqueid` | String | Unique identifier of the user in Pipeimob. |
    | `nome_completo` | String | Full name of the user. |
    | `email` | String | E-mail of the user; matches agente\_gestor\_email and the e-mails in transactions.usuarios\_participantes. |
    | `perfil` | String | Profile of the user (e.g. Corretor, Gestor). |
    | `aprovado` | Boolean | Whether the user is approved (allowed to use the platform). |
    | `creci_numero` | String | CRECI registration number of the broker. |
    | `agencia` | String | Agency the user belongs to. |
    | `celular` | String | Mobile phone of the user. |
    | `data_criacao_usuario` | Datetime | When the user was created (UTC). |
    | `additional_fields` | String (JSON) | Fields Pipeimob returned that have no column of their own, or whose value did not fit it (JSON object). |
  </Accordion>

  <Accordion title="Service Requests">
    Requests (solicitações) opened by or to your agencies since the Start Date, with status, dates, attachments and the linked transaction.

    Table: `service_requests` · Primary key: `uniqueid` · Sync: Full table

    | Field | Type | Description |
    | :- | :- | :- |
    | `uniqueid` | String | Unique identifier of the request. |
    | `protocolo` | Integer | Sequential protocol number of the request. |
    | `papel` | String | How the credentials see the request: solicitada (made to one of your agencies) or solicitante (opened by one of your agencies). |
    | `status` | String | Status of the request: aberta (open), atendida (completed) or rejeitada (rejected). |
    | `modelo_uniqueid` | String | Template the request was opened from; joins with service\_request\_templates.uniqueid. |
    | `modelo_titulo` | String | Title of the template the request was opened from. |
    | `titulo` | String | Title of the request. |
    | `descricao_abertura` | String | Description written by whoever opened the request. |
    | `data_criacao` | Datetime | When the request was opened (UTC). |
    | `data_conclusao` | Datetime | When the request was completed or rejected (UTC); empty while open. |
    | `usuario_abertura_uniqueid` | String | User who opened the request; joins with users.uniqueid. |
    | `usuario_conclusao_uniqueid` | String | User who completed the request; joins with users.uniqueid. |
    | `anexos_abertura` | String (JSON) | Files attached when the request was opened (JSON array of objects with nome and url). |
    | `anexos_conclusao` | String (JSON) | Files delivered when the request was completed (JSON array of objects with nome and url). |
    | `comentario_conclusao` | String | Answer or justification of whoever completed or rejected the request. |
    | `transacao_uniqueid` | String | Transaction the request is linked to, when any; joins with transactions.transacao\_unique\_id\_pipeimob. |
    | `vinculo` | String | Area the request refers to (e.g. marketing, juridico), when it is a standard one. |
    | `vinculo_personalizado_uniqueid` | String | Custom area of the request, created by the network (identifier). |
    | `vinculo_personalizado_nome` | String | Custom area of the request, created by the network (name). |
    | `agencia_solicitante_uniqueid` | String | Agency that opened the request. |
    | `agencia_responsavel_uniqueid` | String | Agency responsible for handling the request. |
    | `urgente` | Boolean | Whether the request was flagged as urgent. |
    | `additional_fields` | String (JSON) | Fields Pipeimob returned that have no column of their own, or whose value did not fit it (JSON object). |
  </Accordion>

  <Accordion title="Service Request Templates">
    Templates from which requests are opened, with the target handling time in days.

    Table: `service_request_templates` · Primary key: `uniqueid` · Sync: Full table

    | Field | Type | Description |
    | :- | :- | :- |
    | `uniqueid` | String | Unique identifier of the template. |
    | `titulo` | String | Title of the template. |
    | `detalhes_iniciais` | String | Guidance shown to whoever opens a request from this template. |
    | `sla_dias` | Integer | Target time to handle a request of this template, in days. |
    | `vinculo` | String | Standard area of the template. |
    | `vinculo_personalizado_uniqueid` | String | Custom area of the template, created by the network (identifier). |
    | `vinculo_personalizado_nome` | String | Custom area of the template, created by the network (name). |
    | `agencia_uniqueid` | String | Agency that owns the template (franchisors publish templates for the network). |
    | `data_criacao` | Datetime | When the template was created (UTC). |
    | `additional_fields` | String (JSON) | Fields Pipeimob returned that have no column of their own, or whose value did not fit it (JSON object). |
  </Accordion>
</AccordionGroup>

## How transactions are kept up to date

A sale counts by the date its **CCV was signed** (`data_contrato`), and Pipeimob is read by that date. Every sync, while Pipeimob's request limits allow, the connector reads:

1. the sales signed since the previous sync (the last day read is read again, since it may have been read before it ended);
2. the list of transactions Pipeimob reports as changed since the previous complete check, and then each changed transaction, one by one. This is how a sale cancelled months later (its CCV date cleared), an archived or unarchived transaction, a corrected value or a CCV date entered late with an older date reach your table. After a pause of any length, the list is read from where the last complete check stopped (see the limits in [Data Quality Considerations](#data-quality-considerations));
3. older sales, until the history reaches the **Start Date**;
4. once the history is complete, the sales of the **Reprocess window (days)** again, when requests are left.

Each transaction is stored once, by `transacao_unique_id_pipeimob`: when it is read again, its row is replaced by the new version, and nothing already loaded is deleted. The column `synced_at` tells when each row was last read.

When a sync uses up its share of requests, it stops where it is (down to the page of a period) and the next sync continues from there; the sync log says what is waiting. The first syncs load the history progressively. Pipeimob returns 25 transactions per request, so with about 40 sales a month and the default limits each day loads one to two months of history; with one sync a day, raising **Listing requests per sync** to 8 speeds it up.

# Use Cases for Data Analysis

The queries below answer common sales questions with the `transactions` table. Run them on [Explorer](https://app.nekt.ai/explorer), replacing the table name with the one you chose. `valor_contrato` is the VGV and `total_comissao` the VGC.

<Note>
  The queries count as a sale a transaction whose CCV was signed in the period (`data_contrato`), that is not a rental (`tipo_transacao`) and that is either active or archived as finished ("Transação Finalizada"). A sale undone in Pipeimob has its CCV date cleared or is archived with another reason. Confirm this definition with your team, since archiving reasons are configured by each agency, and adjust the filters if needed.
</Note>

### 1. Sales, VGV and VGC of a month

```sql theme={null}
SELECT
  COUNT(*) AS sales,
  SUM(valor_contrato) AS vgv,
  SUM(total_comissao) AS vgc,
  AVG(valor_contrato) AS average_ticket
FROM transactions
WHERE data_contrato BETWEEN DATE '2026-10-01' AND DATE '2026-10-31'
  AND tipo_transacao IN ('terceiros', 'lancamento')
  AND (data_arquivamento IS NULL OR arquivamento_motivo_geral = 'Transação Finalizada')
```

### 2. Sales signed between two dates, by broker

Production by broker comes from `comissionados`, which records each participant as of the sale. The query below uses the managing agent and team columns, which show the current registration (see the note in [Fields by stream](#fields-by-stream)).

```sql theme={null}
SELECT
  agente_gestor,
  lider_equipe,
  agente_gestor_grupo_filial,
  COUNT(*) AS sales,
  SUM(valor_contrato) AS vgv,
  SUM(total_comissao) AS vgc
FROM transactions
WHERE data_contrato BETWEEN DATE '2026-09-15' AND DATE '2026-10-15'
  AND tipo_transacao IN ('terceiros', 'lancamento')
  AND (data_arquivamento IS NULL OR arquivamento_motivo_geral = 'Transação Finalizada')
GROUP BY agente_gestor, lider_equipe, agente_gestor_grupo_filial
ORDER BY vgv DESC
```

### 3. Resale versus new developments, and category mix

`tipo_transacao` is `terceiros` for resale (shown as Venda in Pipeimob), `lancamento` for new developments sold for a builder, and `locacao` for rentals.

```sql theme={null}
SELECT
  tipo_transacao,
  categoria,
  COUNT(*) AS sales,
  SUM(valor_contrato) AS vgv,
  AVG(valor_contrato) AS average_ticket
FROM transactions
WHERE data_contrato BETWEEN DATE '2026-01-01' AND DATE '2026-12-31'
  AND (data_arquivamento IS NULL OR arquivamento_motivo_geral = 'Transação Finalizada')
GROUP BY tipo_transacao, categoria
ORDER BY tipo_transacao, vgv DESC
```

### 4. How fresh the data is

```sql theme={null}
SELECT MAX(synced_at) AS last_read_from_pipeimob
FROM transactions
```

## Data Quality Considerations

* **A cancelled sale stays in the table.** When a sale is undone, Pipeimob either clears its CCV date (`data_contrato` becomes empty) or archives it with a reason other than "Transação Finalizada" (`data_arquivamento` and `arquivamento_motivo_geral` filled in). Archiving can be undone, which clears `data_arquivamento` again. Pipeimob returns active and archived transactions together, so filter them as in the queries above.

* **Count sales by `data_contrato`.** Transactions read from Pipeimob's list of changes are loaded whatever their date, including ones whose CCV was never signed; their `data_contrato` is empty, so filtering by period leaves them out. Every sync also checks that the transactions returned for a period have their `data_contrato` inside it, and the sync log warns if they do not.

* **Broker and team show the current registration.** See the note in [Fields by stream](#fields-by-stream): use `comissionados` for production by broker, and a History on the table to keep the team at the time of each sale.

* **`valor_vgc`** is the VGC as Pipeimob computes it (every commission line, including those that do not count as production of their participant). It is filled only when Pipeimob sends it; `total_comissao` is always present.

* **The history arrives over several days.** Until the log stops mentioning older sales, the history before the oldest loaded month is incomplete. Recent sales are loaded first.

* **Changed transactions that cannot be read.** A transaction that Pipeimob lists as changed but does not return (deleted, no longer visible to your credentials) or keeps failing on is asked for again on the next syncs. After 3 different days without success it is retried once a week for up to 4 weeks, and then given up; the sync log gives the count each time. Its row keeps the last version loaded, so a transaction deleted in Pipeimob stays in the table. A given-up transaction that still exists is read again by itself the next time it changes in Pipeimob, or while its CCV date is in the reprocess window; if the message keeps appearing, contact Nekt support with the date of the sync. When Pipeimob fails every such request in a sync, it is treated as a temporary outage and nothing counts against these limits.

* **Backlog limits.** Up to 1,000 changed transactions can wait for their turn; beyond that the oldest move to the weekly retry (which holds up to 500). This only happens when changes come faster than Pipeimob's daily limit of single-transaction requests allows.

* **Order of the change list.** Pipeimob does not document how it orders the list of changed transactions. When a list is read over several syncs, each sync first reads the last page again, which catches a transaction that moved by up to a page; if the list got shorter, it is read again from the start. Within a single sync, a list that changes while it is being read is read again on the next sync. In the rare case where many transactions leave and enter the list between two syncs, one of them could be missed until it changes again.

* **Values** keep the precision Pipeimob returns. `resumo_comissao_*` columns summarize the active commission charges of each transaction; `cobrancas_bancarias` lists every charge with its status.

* **Errors stop the sync.** If Pipeimob refuses the credentials, keeps failing or returns an unexpected answer, the sync stops with a message; the next sync tries again. When a list changes while it is being read, the connector reads it again in smaller parts; if no progress is made for several syncs in a row, the log warns and then the sync stops with an error.

<Warning>
  A full sync of Transactions must read the whole history, one request per 30 days, in a single sync. When that does not fit in the requests a sync may use (usually any Start Date more than a few months back), the sync stops before changing the table. Keep Transactions on INCREMENTAL and do not schedule an Additional Full Sync for it.
</Warning>

## Troubleshooting

| Error or symptom | What it means | What to do |
| :- | :- | :- |
| "Pipeimob rejected the API credentials" | The API Key or API Secret is wrong or no longer active. | Check both fields, or ask Pipeimob support to confirm the credentials. |
| "Pipeimob did not allow these credentials to read ..." | The credentials lack the permission (scope) for that stream. The other streams still sync; the run then fails with this message. | Ask Pipeimob support for the permission, or deselect the stream. |
| "... request limit ... was used up before ..." | The sync used its share of Pipeimob's requests (or other syncs or tools used them in the last 24 hours). | Nothing: the next sync continues from where this one stopped. If it repeats every day, check whether other tools use the same credentials. |
| "A full sync of transactions ... needs at least N requests" | A full sync cannot read the whole history in one sync. | Switch Transactions back to INCREMENTAL. |
| "For N syncs in a row no progress was made" | Pipeimob's lists keep changing while they are read. | Contact Nekt support if it persists. |
| "Pipeimob did not complete the sign-in" | Pipeimob's authentication was unavailable. | Usually temporary; the next sync tries again. If it persists, contact Pipeimob support. |


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