​

Configuring Pipeimob as a Source

​

1. Add account access

• 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).
• 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.

​

2. Select streams

Tip: The stream can be found more easily by typing its name.

​

3. Configure data streams

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

​

4. Configure data source

• 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.
• Determine when to execute an Additional Full Sync. Do not schedule one for Transactions (see the warning in Data Quality Considerations).

​

5. Check your new source

​

Streams and Fields

​

Available streams

​

Fields by stream

​

How transactions are kept up to date

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);
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.

​

Use Cases for Data Analysis

​

1. Sales, VGV and VGC of a month

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

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

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

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

​

Troubleshooting