Skip to main content
Umbler Talk (uTalk) is Umbler’s platform for customer service, sales and chatbots on WhatsApp and other channels. This connector reads your Umbler Talk organization through the Umbler Talk API and brings your contacts, chats and their messages, contact ratings, channels, sectors, tags, custom fields, members, chatbots, WhatsApp Flows and their answers, bulk sends (campaigns) and the messages they delivered, tasks, quick answers and message templates.
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.
The connector sees what the user who created the token sees. Create the token with a user who has the Administrator role in the organization: users below admin only see part of the chats, tasks and settings, and some tables would be skipped.
API access depends on your Umbler Talk plan. If your plan does not include it, the sync fails with a message saying so. Check your plan with Umbler.
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: 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.
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). 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.
For you to be able to see it on your Catalog, you need at least one successful source run.

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.
The Umbler Talk organization read by the source: plan, contract and the features the plan includes.Table: organization · Primary key: id · Sync: Full table
People and AI agents of the organization, with their permissions.Table: organization_members · Primary key: id · Sync: Full table
Channels of the organization: WhatsApp numbers, Instagram accounts, website widgets and others.Table: channels · Primary key: id · Sync: Full table
Sectors (departments) chats are routed to.Table: sectors · Primary key: id · Sync: Full table
Tags used on contacts and chats.Table: tags · Primary key: id · Sync: Full table
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 table
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 table
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 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)
Ratings (satisfaction surveys) given by contacts.Table: contact_ratings · Primary key: id · Sync: Incremental (by created_at_utc)
Chatbots of the organization.Table: bots · Primary key: id · Sync: Full table
WhatsApp Flows (forms) of the organization.Table: flows · Primary key: id · Sync: Full table
Answers contacts sent to the WhatsApp Flows.Table: flow_answers · Primary key: id · Sync: Incremental (by answered_at_utc)
Bulk sends (campaigns) of templates or chatbots.Table: bulk_send_sessions · Primary key: id · Sync: Full table
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 of the organization, linked to chats, contacts or pipeline items.Table: organization_tasks · Primary key: id · Sync: Full table
Quick answers (saved replies) of every member.Table: quick_answers · Primary key: id · Sync: Full table
WhatsApp message templates and their approval status.Table: templates · Primary key: id · Sync: Full table

Implementation 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_state of 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 _utc and 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.