The connector only reads data. It never creates, changes or deletes anything in Teamwork Desk.
Configuring Teamwork Desk as a Source
In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Teamwork Desk option from the list of connectors. Click Next and you’ll be prompted to add your access.1. Add account access
The Teamwork Desk API uses an API key created by a user of your site. To create one, open Teamwork Desk, click your avatar in the bottom left, click View Profile, go to API Keys and click Create an API key. Copy the key.- Teamwork Site Address: the address of your Teamwork site, as shown in your browser when Teamwork Desk is open, without the
/deskpart. For examplehttps://acme.teamwork.com,https://acme.eu.teamwork.comif your site is hosted in the EU, or your custom domain such ashttps://support.example.com. Onlyhttpsaddresses are accepted. - API Key: the key copied from Teamwork Desk.
- Start Date: the earliest date synced on the first sync and on full syncs. Tickets (with their messages), customers, companies, satisfaction ratings and time logs last updated since this date are loaded. Users, inboxes and the help desk settings are always loaded whole.
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. Tickets, Ticket Messages, Customers, Companies, Happiness Ratings and Time Logs are Incremental: each sync reads only what changed since the previous one and merges it into the table. The other tables are Full table: 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). Tickets 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. 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.
Tables join on their ids:
ticket_messages.ticket_id, happiness_ratings.ticket_id and timelogs.ticket_id = tickets.id; tickets.customer_id = customers.id; customers.company_id and tickets.company_id = companies.id; tickets.inbox_id = inboxes.id; tickets.status_id, priority_id, type_id and source_id = the id of Ticket Statuses, Ticket Priorities, Ticket Types and Ticket Sources; tickets.agent_id and timelogs.user_id = users.id; custom_field_options.custom_field_id = custom_fields.id; happiness_ratings.happiness_rating_option_id = happiness_rating_options.id.
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. Lists of related records (for exampletickets.tags) come as JSON arrays of {"id": ..., "type": ...} objects; join the ids with the matching table. Dates and times are in UTC.
Tickets
Tickets
Help desk tickets of every state (active, scheduled, merged and deleted) updated since the Start Date, with their inbox, status, priority, type, source, agent, customer, SLA and counters. Each sync reads the tickets changed (or deleted) since the previous one.Table:
tickets · Primary key: id · Sync: Incremental (updated_at)Ticket Messages
Ticket Messages
The conversation of each ticket: customer and agent replies, notes, forwards and events, with their text and HTML body. Each sync reads all the messages of the tickets changed since the previous one.Table:
ticket_messages · Primary key: id · Sync: Incremental (ticket_updated_at)Customers
Customers
Customers (the people who contact your help desk) updated since the Start Date, with their contact details and company.Table:
customers · Primary key: id · Sync: Incremental (updated_at)Companies
Companies
Companies (and custom groups) your customers belong to, updated since the Start Date.Table:
companies · Primary key: id · Sync: Incremental (updated_at)Happiness Ratings
Happiness Ratings
Satisfaction (happiness) ratings customers gave to tickets, updated since the Start Date. Ratings deleted in Teamwork Desk are kept with
state = deleted.Table: happiness_ratings · Primary key: id · Sync: Incremental (updated_at)Time Logs
Time Logs
Time logged by agents on tickets, updated since the Start Date. Time logs deleted in Teamwork Desk are kept with
state = deleted, so add WHERE state <> 'deleted' when summing hours.Table: timelogs · Primary key: id · Sync: Incremental (updated_at)Users
Users
Agents and admins of your Teamwork Desk, archived ones included.Table:
users · Primary key: id · Sync: Full tableInboxes
Inboxes
Inboxes (shared and personal) and their settings. The SMTP password is never loaded.Table:
inboxes · Primary key: id · Sync: Full tableTicket Priorities
Ticket Priorities
Priorities a ticket can have.Table:
ticket_priorities · Primary key: id · Sync: Full tableTicket Statuses
Ticket Statuses
Statuses a ticket can have, built-in and custom.Table:
ticket_statuses · Primary key: id · Sync: Full tableTicket Sources
Ticket Sources
Channels a ticket can come from (email, phone, chat, API…).Table:
ticket_sources · Primary key: id · Sync: Full tableTicket Types
Ticket Types
Types a ticket can have.Table:
ticket_types · Primary key: id · Sync: Full tableSLAs
SLAs
Service level agreements and what they apply to.Table:
slas · Primary key: id · Sync: Full tableBusiness Hours
Business Hours
Business hours used by SLAs, with their schedules and holidays.Table:
business_hours · Primary key: id · Sync: Full tableCustom Fields
Custom Fields
Custom fields defined for tickets.Table:
custom_fields · Primary key: id · Sync: Full tableCustom Field Options
Custom Field Options
Options of the dropdown and checkboxes custom fields.Table:
custom_field_options · Primary key: id · Sync: Full tableHappiness Rating Options
Happiness Rating Options
Answers a customer can choose when rating a ticket.Table:
happiness_rating_options · Primary key: id · Sync: Full tableCanned Responses
Canned Responses
Saved replies agents can insert in tickets.Table:
canned_responses · Primary key: id · Sync: Full tableImplementation Notes
Data Quality Considerations
- How tickets stay up to date. Each sync reads the tickets updated since the previous one (minus 10 minutes, to cover changes still being saved in Teamwork Desk) up to the moment the sync started; a ticket updated while a sync runs is read by the next sync. Tickets of every state are read: active, scheduled, merged and deleted. Deleting a ticket does not change its last update date, so the connector also reads the tickets deleted since the previous sync, and they appear with
state=deleted. - Ticket messages. Teamwork Desk lists messages ticket by ticket. When a ticket changes (for example, a new reply), the next sync reads all its messages again and merges them by message id. The sync also reads the messages of every ticket that had any activity since the previous sync, even if its last update date did not change, and warns in the sync log if Teamwork Desk added new messages without updating their ticket. Tickets with activity that the API key’s user cannot see are skipped. The messages of deleted tickets are not read again and stay as last loaded. If Teamwork Desk says a ticket’s messages are not found, the sync checks the ticket: when it was deleted, merged into another ticket or no longer exists, it is skipped; otherwise the table fails.
- Delivery and view details of messages. Fields such as
delivery_status,viewed_by_customer_at,reactionsandlikescan change without any activity on the ticket; they are refreshed the next time the ticket changes, so they may lag behind Teamwork Desk. - Long histories are read in steps. Tickets are read 30 days at a time (messages 7 days at a time; customers, companies, ratings and time logs 90 days at a time), oldest first. On the first sync and on a full sync, a table only counts as done when every period was read: if it stops halfway, the next sync starts it again. When a source catches up after a pause, each period is saved as it goes, and a sync that stops halfway continues from the last period saved.
- Full table tables are never half updated. The connector reads all the data of a full table table before writing any of it. If Teamwork Desk fails while it is read, nothing of that table is sent and the sync shows it as failed. 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 Teamwork Desk, run a full sync of the source to accept it.
- Complete reads. Lists are read page by page and checked against the number of records Teamwork Desk reports. If records disappear while a list is read (for example, a customer deleted during the sync), the list is read again; if it still does not add up, the table fails instead of loading incomplete data.
- Deleted records. Tickets, time logs and satisfaction ratings deleted in Teamwork Desk are loaded with
state=deletedand theirdeleted_atdate. Filter them out in your analyses (for exampleWHERE state <> 'deleted'when summingtimelogs.seconds). Deleted customers and companies are not reported, so they stay in the table as last loaded. - Features not available to the key. If Teamwork Desk refuses the API key access to an area (for example, SLAs, time logs or satisfaction ratings not included in your plan, or not allowed for the key’s user), or answers with an error when the sync checks it, the tables of that area are shown as failed with a message saying so, and the other tables keep syncing. An invalid key, or a site address that is not your Teamwork site, fails the sync with a message saying what to check.
- Custom field values. Custom fields of a ticket come in
tickets.custom_fieldsas a JSON list with the custom field id and, when Teamwork Desk sends it, the value. - Secrets. Passwords stored in Teamwork Desk (such as an inbox SMTP password) are never loaded.
API Limits & Performance
- Teamwork Desk allows 120 requests per minute per site, shared by every integration of your site. The connector sends at most 100 per minute and, when Teamwork Desk asks it to wait, waits and tells you in the sync log.
- Lists are read up to 100 records per request: 10,000 tickets take about 100 requests (one minute).
- Ticket Messages needs one request per changed ticket (and one more per extra 100 messages). A first sync of 10,000 tickets takes about 2 hours; later syncs only read the tickets that changed, so they are quick. On a large help desk, choose a recent Start Date (for example, the last few months) for the first sync, or deselect Ticket Messages if you do not need the conversations.
- Users, inboxes and the settings tables are read whole on every sync; they are small and take a few requests each.