Skip to main content
Teamwork Desk is the help desk of Teamwork.com: emails and other channels arrive in inboxes and become tickets, handled by agents, classified by status, priority, type and tags, and measured against SLAs and satisfaction ratings. This connector reads your site’s data through the official Teamwork Desk API (v2) and brings your tickets with their whole conversation (messages), your customers and companies, satisfaction ratings, time logs, users and inboxes, plus the help desk settings: tags, statuses, priorities, sources, types, SLAs, business hours, custom fields and canned responses.
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 /desk part. For example https://acme.teamwork.com, https://acme.eu.teamwork.com if your site is hosted in the EU, or your custom domain such as https://support.example.com. Only https addresses 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.
The connector sees exactly what the user who created the API key sees. Create the key with a user that has access to every inbox you want to sync; tickets of inboxes that user cannot open are not loaded. If the key is deleted, or the user loses access, update the API Key of this source.
Teamwork Desk allows 120 requests per minute per site, shared by every integration of your site. The connector stays at 100 per minute and waits when Teamwork Desk asks it to, so a long history takes a while on the first sync.
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. 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.
Avoid setting Ticket Messages to Full table. Teamwork Desk lists messages one ticket at a time, so every sync would read again the messages of every ticket updated since the Start Date, which takes hours on a large help desk.
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). 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.
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. 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 example tickets.tags) come as JSON arrays of {"id": ..., "type": ...} objects; join the ids with the matching table. Dates and times are in UTC.
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)
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 (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 (and custom groups) your customers belong to, updated since the Start Date.Table: companies · Primary key: id · Sync: Incremental (updated_at)
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 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)
Agents and admins of your Teamwork Desk, archived ones included.Table: users · Primary key: id · Sync: Full table
Inboxes (shared and personal) and their settings. The SMTP password is never loaded.Table: inboxes · Primary key: id · Sync: Full table
Tags that can be applied to tickets.Table: tags · Primary key: id · Sync: Full table
Priorities a ticket can have.Table: ticket_priorities · Primary key: id · Sync: Full table
Statuses a ticket can have, built-in and custom.Table: ticket_statuses · Primary key: id · Sync: Full table
Channels a ticket can come from (email, phone, chat, API…).Table: ticket_sources · Primary key: id · Sync: Full table
Types a ticket can have.Table: ticket_types · Primary key: id · Sync: Full table
Service level agreements and what they apply to.Table: slas · Primary key: id · Sync: Full table
Business hours used by SLAs, with their schedules and holidays.Table: business_hours · Primary key: id · Sync: Full table
Custom fields defined for tickets.Table: custom_fields · Primary key: id · Sync: Full table
Options of the dropdown and checkboxes custom fields.Table: custom_field_options · Primary key: id · Sync: Full table
Answers a customer can choose when rating a ticket.Table: happiness_rating_options · Primary key: id · Sync: Full table
Saved replies agents can insert in tickets.Table: canned_responses · Primary key: id · Sync: Full table

Implementation 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, reactions and likes can 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 = deleted and their deleted_at date. Filter them out in your analyses (for example WHERE state <> 'deleted' when summing timelogs.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_fields as 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.