The connector only reads data. It never sends messages or creates, changes or deletes anything in Umbler Talk. This is the Umbler Talk connector; for Umbler hosting, domains and e-mail, use the Umbler connector.
Configuring Umbler Talk as a Source
In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Umbler Talk option from the list of connectors. Click Next and you’ll be prompted to add your access.1. Add account access
The Umbler Talk API uses an access token. To create one, open Umbler Talk, click your profile picture and go to Access Tokens, then create a token and copy it.- API Token: the access token you created.
- Start Date: the earliest date read by the incremental tables (chats, messages, ratings, WhatsApp Flow answers and bulk send messages). The other tables are always read whole.
- Organization ID (advanced, optional): leave it empty when your user belongs to a single Umbler Talk organization. If it belongs to more than one, the first sync fails and its log lists your organizations with their IDs; copy the ID of the one to sync into this field.
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: keep the suggested type. Chats, Messages, Contact Ratings, WhatsApp Flow Answers and Bulk Send Messages are Incremental: each sync reads only what changed since the previous one and merges it into the table. The other tables are Full table: the Umbler Talk API has no filter by date for them, so each sync reads them whole and replaces the table.
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). Chats and messages are read incrementally, so an hourly or daily sync works well. Optionally, you can 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. Chats and Messages catch conversations that receive new messages without one. An Additional Full Sync (for example, weekly) is still useful to refresh what incremental syncs do not see: chats closed or transferred without a new message, and message states or reactions that change more than 3 days after the message (see 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 page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.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.Fields by stream
Fields marked String (JSON) hold a nested object or list as JSON text; use your warehouse’s JSON functions to read them.Organization
Organization
The Umbler Talk organization read by the source: plan, contract and the features the plan includes.Table:
organization · Primary key: id · Sync: Full tableOrganization Members
Organization Members
People and AI agents of the organization, with their permissions.Table:
organization_members · Primary key: id · Sync: Full tableChannels
Channels
Channels of the organization: WhatsApp numbers, Instagram accounts, website widgets and others.Table:
channels · Primary key: id · Sync: Full tableSectors
Sectors
Sectors (departments) chats are routed to.Table:
sectors · Primary key: id · Sync: Full tableCustom Field Definitions
Custom Field Definitions
Custom fields defined for contacts and chats. Their values are in the
custom_fields column of Contacts and Chats, linked by customFieldDefinitionId.Table: custom_field_definitions · Primary key: id · Sync: Full tableContacts
Contacts
Every contact of the organization, blocked contacts and WhatsApp groups included, with the values of every contact custom field.Table:
contacts · Primary key: id · Sync: Full tableChats
Chats
Conversations of every state (open, waiting and closed), pinned chats included. A chat is loaded again whenever it gets a new message, with its latest state.Table:
chats · Primary key: id · Sync: Incremental (by event_at_utc)Messages
Messages
Messages of the chats read in each sync. For each chat, messages are read from 3 days before the sync window, so an old conversation that gets a new message only adds its recent messages, and recent messages get their latest delivery state. Binary file content is never loaded (the file URL, name, type and size are).Table:
messages · Primary key: id · Sync: Incremental (by event_at_utc)Contact Ratings
Contact Ratings
Ratings (satisfaction surveys) given by contacts.Table:
contact_ratings · Primary key: id · Sync: Incremental (by created_at_utc)Chatbots
Chatbots
Chatbots of the organization.Table:
bots · Primary key: id · Sync: Full tableWhatsApp Flows
WhatsApp Flows
WhatsApp Flows (forms) of the organization.Table:
flows · Primary key: id · Sync: Full tableWhatsApp Flow Answers
WhatsApp Flow Answers
Answers contacts sent to the WhatsApp Flows.Table:
flow_answers · Primary key: id · Sync: Incremental (by answered_at_utc)Bulk Sends
Bulk Sends
Bulk sends (campaigns) of templates or chatbots.Table:
bulk_send_sessions · Primary key: id · Sync: Full tableBulk Send Messages
Bulk Send Messages
Each message a bulk send delivered, with its delivery state. Every sync reads again the bulk sends created in the 30 days before the newest one already loaded, so delivery states keep updating while they can still change.Table:
bulk_send_messages · Primary key: bulk_send_session_id, message_id · Sync: Incremental (by session_created_at_utc)Tasks
Tasks
Tasks of the organization, linked to chats, contacts or pipeline items.Table:
organization_tasks · Primary key: id · Sync: Full tableQuick Answers
Quick Answers
Quick answers (saved replies) of every member.Table:
quick_answers · Primary key: id · Sync: Full tableMessage Templates
Message Templates
WhatsApp message templates and their approval status.Table:
templates · Primary key: id · Sync: Full tableImplementation Notes
Data Quality Considerations
- How chats and messages stay up to date. Each sync reads, in order of their last message, the chats that got a message since the previous sync (with a 2-hour margin), up to the moment the sync started, plus your pinned chats. For each of them it reads the messages of that period and of the 3 days before it. A conversation that started months ago and gets a new message today is updated in Chats and its recent messages are added to or refreshed in Messages. A chat that gets a message while a sync is running is read by the next sync. If a sync is interrupted, the next one continues where it stopped, and still loads the full message period of the chats the interrupted sync had not reached. Chats that have no message yet are read too.
- Closings and transfers. A chat whose only change is a closing or a transfer, without a new message, is refreshed in Chats when it gets its next message or in a full sync.
- Message states. The
message_stateof a message (sent, received, read) and its reactions are refreshed whenever its chat is read within 3 days of the message. Later changes are only picked up by a full sync. In Bulk Send Messages, delivery states are read again for 30 days after each campaign. - Late messages. Message times come from the messaging provider. A message that reaches Umbler Talk up to about 3 days after its own time is loaded the next time its chat is read; later than that, only by a full sync. The same applies when syncs are more than 3 days apart.
- Message history limited by plan. Some Umbler Talk plans limit how far back messages can be read. When that happens, the sync log warns once, and the older messages are not available to the connector.
- Full table tables are never half updated. The connector reads all the data of a full table table before writing any of it. If Umbler Talk fails or refuses part of it, nothing of that table is sent and the sync shows it as failed. On GCP (BigQuery) the table keeps its previous content; on AWS, a full table table whose stream was skipped may be emptied by the load step until the next successful sync. A full table table that suddenly comes back empty is not emptied either: the sync fails for that table. If the data really was removed in Umbler Talk, run a full sync of the source to accept it.
- Permissions. Tables the token’s user may not read are skipped, shown as failed in the sync, and named in the sync log; the other tables keep syncing. If Umbler Talk refuses the messages of a chat or no longer has them, that chat’s messages are skipped, everything else is loaded, and the chat is tried again in the next sync. For a private chat of other members, the sync log only warns (use a token of an Administrator to include them); if it is refused again in the next sync, it is no longer retried. For any other chat, the Messages table is also shown as failed in that sync, so missing messages never go unnoticed. A chat is dropped from the retries only when Umbler Talk confirms it was deleted. At most 500 chats are kept for retry.
- Scheduled messages are not extracted. The Umbler Talk API only lists them one contact at a time.
- Times are in UTC in every column ending in
_utcand in every other date column.
API Limits & Performance
- Umbler Talk allows up to 100 requests every 5 seconds, shared with your other integrations. The connector makes at most about 10 requests per second and, when Umbler Talk asks it to slow down, waits and tells you in the sync log.
- Lists are read 50 records per request, and messages 250 per request per chat. The first sync reads everything since the Start Date and can take a while on large accounts; later syncs read only what changed in Chats, Messages and the other incremental tables, and read the full table tables whole.
Troubleshooting
Skills for agents
Download Umbler Talk skills file
Umbler Talk connector documentation as plain markdown, for use in AI agent contexts.