Skip to main content
Hub ConsultIA is ConsultIA’s platform that combines a CRM with omnichannel customer service (WhatsApp, e-mail and chat), AI agents and dashboards. This connector reads your Hub ConsultIA account through its public API and brings your pipelines and deals, contacts, companies and tasks, the CRM catalogs (loss reasons, deal origins, task categories, custom fields and tags), your service conversations with their messages and history, and the numbers of the Dashboard: attendances, satisfaction surveys (CSAT) and commercial results.
The connector only reads data. It never creates, changes or deletes anything in Hub ConsultIA.

Configuring Hub ConsultIA as a Source

In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Hub ConsultIA option from the list of connectors. Click Next and you’ll be prompted to add your access.

1. Add account access

The connector signs in with a Hub ConsultIA API key. In Hub ConsultIA, open Integrações in the side menu, go to the Chaves de API tab and click Nova chave. Name the key (for example, “Nekt”) and give it Leitura (read) access to every module you want to sync: CRM, Catálogo, Conversas, Conexões, Manuais and Relatórios. Copy the key when it is shown.
Hub ConsultIA allows 100 requests per minute per API key. Create a key used only by Nekt, so that other integrations don’t slow down your syncs (or the other way around).
The following configurations are available:
  • API Key: The Hub ConsultIA API key.
  • Start Date: Earliest date read by the incremental streams (conversation messages, history and linked cards, attendances, survey answers and the daily reports) on the first sync and on full syncs. CRM lists and the conversation list are always read in full.
  • Account Time Zone (advanced, optional): The time zone of your Hub ConsultIA account (for example, America/Sao_Paulo or America/Manaus), used to cut report days. Leave it empty and the connector reads it from Hub ConsultIA; if it cannot, it uses America/Sao_Paulo and says so in the sync log.
  • Deal Details Full Read Interval (days) (advanced): Only used by the Deal Details stream. Between full reads it reads only the deals updated since the last sync; every this many days it reads every deal again, to catch contacts or tasks linked to a deal without changing it. 0 reads every deal on every sync. Default: 7.
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, 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.
  • Determine when to execute an 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 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, you need at least one successful source run.
Because of the limit of 100 requests per minute, streams that read one record at a time take longer, so they are not selected by default: Deal Tag Assignments makes one request per deal and Person Tags one per contact on every sync (with 10,000 deals, about two hours), and Deal Details one per deal on the first sync and every 7 days (configurable), and in between only for deals updated since the last sync. Conversation history and linked cards are read only for conversations with recent activity or still open, so after the first sync they are fast. As a rough estimate based on the number of requests (not a measurement), an account with 10,000 deals, 50,000 contacts and 20,000 conversations needs about 2,350 requests a day for the default selection, around 30 minutes at the allowed pace plus the API’s response time.
When Hub ConsultIA lists the messages of a conversation, it transcribes on the spot every audio message that does not have a transcription yet, and this uses your Hub ConsultIA credits. The first sync of Conversation Messages can trigger many transcriptions. That is why this stream is not selected by default: select it only if you want the messages, preferably with a recent Start Date.

Fields by stream

CRM

Sales and task pipelines (funnels) of the account, with their stages as listed with them.Table: pipelines · Primary key: id · Sync: Full table
Stages (columns) of every pipeline, with the status a deal gets when it enters each one.Table: pipeline_stages · Primary key: id · Sync: Full table
Task categories enabled on each task pipeline (kanban).Table: pipeline_task_categories · Primary key: pipeline_id, id · Sync: Full table
Deals (negócios) with their value, status, pipeline, stage, company, owner and supervisor.Table: deals · Primary key: id · Sync: Full table
Every deal read one by one, with its linked people, tasks, products and the history of its moves between stages. After the first sync, only deals updated since the last sync are read again. Not selected by default.Table: deal_details · Primary key: id · Sync: Incremental · Replication key: updated_at
Which tags are on which deal. One request per deal on every sync. Not selected by default.Table: deal_tag_assignments · Primary key: deal_id, tag_id · Sync: Full table
Catalog of deal tags.Table: deal_tags · Primary key: id · Sync: Full table
Contacts with phones, e-mails, CPF and company.Table: persons · Primary key: id · Sync: Full table
Which tags are on which contact. One request per contact on every sync. Not selected by default.Table: person_tags · Primary key: person_id, tag_id · Sync: Full table
Companies with legal name, CNPJ, domain and ICP flag.Table: companies · Primary key: id · Sync: Full table
Tasks with status, priority, due date and what they are linked to.Table: tasks · Primary key: id · Sync: Full table
Reasons a deal can be lost.Table: lost_reasons · Primary key: id · Sync: Full table
Origins of deals.Table: deal_sources · Primary key: id · Sync: Full table
Tree of task categories.Table: task_categories · Primary key: id · Sync: Full table
Definitions of the custom fields of deals, contacts, companies and tasks. Their values are in the custom_fields column of each entity, keyed by slug.Table: custom_fields · Primary key: id · Sync: Full table

Conversations

Service conversations (WhatsApp, e-mail, chat) with status, priority, responsible user, department and current attendance.Table: conversations · Primary key: id · Sync: Full table
Messages of each conversation, including internal notes and audio transcriptions. Not selected by default (see the warning about transcription credits).Table: conversation_messages · Primary key: id · Sync: Incremental · Replication key: created_at
Events of each conversation: assignments, transfers, stage and status changes, tags.Table: conversation_history · Primary key: id · Sync: Incremental · Replication key: created_at
Deals and tasks linked to each conversation. A card later unlinked keeps its row.Table: conversation_linked_cards · Primary key: conversation_id, type, id · Sync: Incremental · Replication key: conversation_activity_at
Active channels (connections) of the account. Never includes credentials or phone numbers.Table: connections · Primary key: id · Sync: Full table
Published manuals indexed in the AI memory, with their indexing status.Table: manuals · Primary key: manual_id · Sync: Full table

Reports

Every attendance (each reopening of a conversation is a new attendance) with responsible user, department, inbox and its times, in business hours and elapsed. Attendances that finish later are updated whenever they finish.Table: attendance_cycles · Primary key: id · Sync: Incremental · Replication key: started_at
The Dashboard’s attendance numbers, one row per day.Table: attendance_summary_daily · Primary key: report_date · Sync: Incremental · Replication key: report_date
Attendance volume and times per agent, one row per agent per day. A row the report no longer has on a re-read is kept with removed = true and empty figures.Table: attendance_by_agent_daily · Primary key: report_date, agent_key · Sync: Incremental · Replication key: report_date
Average times per department, one row per department per day. A row the report no longer has on a re-read is kept with removed = true and empty figures.Table: attendance_by_department_daily · Primary key: report_date, department_key · Sync: Incremental · Replication key: report_date
The queue at the moment of each sync: open conversations with and without a responsible user. One row per sync; a full sync replaces the table and loses that history.Table: attendance_queue_snapshots · Primary key: snapshot_at · Sync: Incremental · Replication key: snapshot_at
Satisfaction survey answers, one per row.Table: csat_responses · Primary key: id · Sync: Incremental · Replication key: sent_at
Survey summary (sent, answered, average, satisfaction), one row per day.Table: csat_summary_daily · Primary key: report_date · Sync: Incremental · Replication key: report_date
Survey results per agent, one row per agent per day. A row the report no longer has on a re-read is kept with removed = true and empty figures.Table: csat_by_agent_daily · Primary key: report_date, agent_key · Sync: Incremental · Replication key: report_date
Survey results per department, one row per department per day. A row the report no longer has on a re-read is kept with removed = true and empty figures.Table: csat_by_department_daily · Primary key: report_date, department_key · Sync: Incremental · Replication key: report_date
The Dashboard’s commercial numbers (deals created, won, lost, values, funnel, sales per seller), one row per day.Table: commercial_summary_daily · Primary key: report_date · Sync: Incremental · Replication key: report_date
Deals per origin, stage and status, one row per combination per day and commercial pipeline. When a deal moves, the combination it left is kept with removed = true and empty figures, so filter on removed = false.Table: commercial_origins_daily · Primary key: report_date, pipeline_id, row_key · Sync: Incremental · Replication key: report_date

Implementation notes

  • Full table streams. Hub ConsultIA’s CRM lists have no “updated since” filter, so pipelines, deals, contacts, companies, tasks, the catalogs and the conversation list are read in full on every sync. If one that had records suddenly comes back empty, that stream fails instead of emptying your table, and its table keeps its data; run a full sync of the source if the data really was removed in Hub ConsultIA. If one comes back with far fewer records than the previous sync, the sync loads it and shows a warning.
  • Deal details. After the first sync, only deals whose last update moved are read again, and every deal is read again every 7 days (see Deal Details Full Read Interval), so a contact or task linked to a deal without changing it shows up within a week. You don’t need an Additional Full Sync for this; a full sync of the source also erases the Attendance Queue Snapshots history.
  • Conversations. Messages, history and linked cards are read for conversations with activity since the last sync (re-reading the last 3 days), and for every conversation that is still open (with activity in the last 30 days) or was open at the previous sync, so the events of closing a conversation are not missed. Finished conversations count as closed; conversations awaiting the satisfaction survey still count as open. A deal or task unlinked from a conversation keeps its row in Conversation Linked Cards.
  • Daily reports. Each daily report is asked for one day at a time, in your account’s time zone (the connector reads it from Hub ConsultIA at the start of each sync, or uses Account Time Zone when set, and warns you if it changes between syncs), and every sync asks the last 7 days again because recent days still change. The summaries have one row per day; the reports by agent, by department and by origin have one row per day and agent, department or origin/stage/status. When a re-read day no longer has a row (an attendance reassigned to another agent, a deal that moved to another stage), that row is kept with removed set to true and empty figures, so filter on removed = false. Daily averages cannot be summed: to get the average of a longer period, weight each day by its sample size.
  • Report days older than 7 days are frozen. Days before the 7-day re-read are never asked again, so records imported later with past dates do not change them. The commercial reports also group deals by the day they were created but show each deal’s stage when the day was read, so an old day does not follow later moves. For the current state of your funnel, use the Deals table.
  • Attendances are read twice for the re-read days: the ones that finished in those days, however long ago they started, and the ones that started in them, including those still in progress. An attendance therefore gets its end time on the sync after it finishes.
  • Survey answers are read up to yesterday (today’s answers come on the next sync) and from 7 days before the latest one already read. A survey answered more than 7 days after it was sent is only picked up by a full sync.
  • Attendance queue snapshots keep one row per sync. A full sync replaces the table and loses the earlier snapshots.
  • Permissions. Before reading anything, the connector checks that the API key can read every module of the streams you selected; if not, the sync stops with a message naming the missing permissions. A report your account or key cannot read (for example, when the CSAT module is not enabled) is skipped with a warning, and the other streams still load.
  • Deleted records. Hub ConsultIA does not report deleted records. Full table streams drop them on the next sync; in incremental tables (messages, history, attendances, survey answers, deal details) a deleted record stays.
  • Fields. Columns follow every field Hub ConsultIA documents for each record. Any other field the API returns is kept in the extra_fields column of the table, as JSON with the original field names.