Connecting Autotask (Datto PSA)

The Autotask connector lets Bridge sync companies, contacts, tickets, and other records between your Autotask (Datto PSA) instance and the platform. The connector uses Autotask's REST API and authenticates with an API integration code plus a dedicated API user account.

What You Need Before Starting

You need three items from Autotask:

• ApiIntegrationCode — a code that identifies your integration; created in Autotask under Admin > Resources/Users (HR) > API Tracking Identifier, or provided by Datto
• UserName — the username of a dedicated API-only resource in Autotask (Autotask recommends creating a separate API user rather than using a staff login)
• Secret — the password for that API user

The API user's security level must grant access to read (and write, if using outbound sync) the entity types you intend to sync.

Creating the Connection

1. Open Bridge and go to Connections.
2. Click New Connection and select Autotask from the platform list.
3. Enter a name for the connection (for example, "Autotask - Main").
4. Enter ApiIntegrationCode, UserName, and Secret.
5. Click Test Connection. Bridge encrypts your credentials and makes a live call to the Autotask API. A successful test sets the connection status to Active. If it fails, the error is shown on the connection — verify the ApiIntegrationCode, confirm the API user credentials are correct, and check the API user's security level.
6. Click Save.

What Can Sync

The Autotask connector supports the following entity types:

• Companies (Accounts) — client account records
• Contacts — contacts attached to accounts
• Tickets — service desk tickets including status, priority, queue, description, and time entries
• Configurations (Configuration Items) — CIs attached to accounts

Select the entity types you want when creating a sync profile or running a historical import.

Sync Direction and Frequency

Once the connection is active, go to Sync Profiles and create a new profile. Pick the Autotask connection, choose entity types, set direction (inbound, outbound, or bidirectional), and set a frequency. You can trigger a manual sync at any time from the profile.

Cursor-Based Pagination

The Autotask connector uses cursor-based pagination, which means it can handle large result sets efficiently without missing records or re-processing pages. If a sync run is interrupted, restarting it will pick up from where it left off.

FAQ

What Autotask API version does Bridge use? Bridge uses the Autotask REST API (v1.0). The legacy SOAP API is not used.

My connection test fails — what should I check? Confirm the ApiIntegrationCode is active and not expired. Check that the UserName and Secret belong to an API-type resource (not a regular staff user). Autotask API users must be of type "API Only."

Can I sync service notes or attachments? Yes. The connector syncs ticket notes, time-entry note text, and ticket attachments (files are downloaded and stored in the platform's attachment blob store; URL-type attachments are flagged rather than stored as files). All three carry fail-closed visibility mapping — see below. ⚠️ The three entities use three different rules and three different field sets; do not carry a conclusion from one to another.

Visibility Mapping (important)

Autotask expresses "who may read this text" on two different entities, with two different field pairs, and they do not follow the same rule. Both are covered below. Read both — a ticket's customer-facing conversation frequently lives in the time entries, not the ticket notes.

The platform's three visibility tiers are a WIDENING LADDER, not three separate boxes

Each tier adds an audience to the one below it. "Public" does not mean "customers only" — it means everyone who should have access, which includes your own staff.

So a public reply is still visible to staff and to co-managed users; it is simply also visible to the customer. Import decisions are fail-closed: anything ambiguous lands on the narrowest tier (msp_only), so an internal note can never leak to a customer.

1. Ticket notes — noteType + publish

The two fields are noteType ("what kind of note is this") and publish ("which Autotask audience was it published to").

⚠️ publish has no customer-visible value. Verified against a live Autotask instance, the TicketNotes.publish picklist is exactly:

1 = All Autotask Users
2 = Internal Project Team
4 = Internal & Co-Managed

All three are internal scopes — "All Autotask Users" means every user inside Autotask, i.e. MSP staff, not the end customer. Autotask expresses customer visibility through the note type (18 Client Portal Note, 19 Taskfire Note) or through the note having been authored by a customer contact, never through publish.

Autotask picklist ids are installation-specific. If your instance genuinely does use a publish id to mean "customer-visible", declare it explicitly per connection via note_visibility_config on the single-ticket sync. Nothing is inferred — with no configuration, no publish id can make a note public on its own.

2. Time entries — which note field is populated, plus one flag

An Autotask TimeEntry carries up to two separate pieces of note text at two different visibility tiers on the same record, and — unlike a ticket note — it has no publish picklist at all. Its two visibility-bearing fields are:

• which text field the words are in — summaryNotes (the customer-facing work summary, the text that appears on an invoice) vs internalNotes (staff-only)

• isInternalNotesVisibleToComanaged — a boolean that widens internalNotes by one rung

⚠️ One time entry can therefore produce TWO timeline items at DIFFERENT tiers. If an entry has both a customer summary and an internal note, the import emits one platform note per populated field, so the customer sees only the summary while your staff see both. The time-entry record itself is also tagged with the widest tier its text reaches, so the logged-time row can be badged in the conversation.

timeEntryType (1 = TroubleTicket, 5 = Activity, 12 = TravelTime, …) is the only picklist on a TimeEntry. It describes what kind of work was logged and has no bearing on visibility. Nor does showOnInvoice, which controls invoice presentation only.

Why this matters for a migration. In Autotask it is common practice for technicians to send customer replies as the summary of a time entry rather than as a ticket note — the reply and the logged time are one action. On such a ticket the ticket notes can be entirely notification stubs and workflow noise while the whole customer conversation sits in summaryNotes. If time-entry text is not imported, the ticket arrives in the platform looking like it has no customer conversation at all.

3. Attachments — a DIFFERENT picklist from notes

Attachments do not share the note rules and must not be routed through the note resolver — that substitution caused the 2026-07-24 incident in which 34 imported attachments, including raw OriginatingEmail.eml files, were customer-downloadable for ~53 hours. Read live from AttachmentInfo/entityInformation/fields (JPtheGeek, zone ww14, as-of 2026-07-26):

⚠️ Note the middle label differs from TicketNotes (2 = Internal Project Team there, 2 = Internal Users Only here) — the two enums are separate and must not be shared in code.

There is no customer-visible value in the attachment publish picklist at all, and an attachment carries no noteType, so there is no positive signal for "public" to derive from. Attachments are always internal unless an operator explicitly configures customer_visible_publish_ids, which defaults to EMPTY.

Two other attachment fields are informative but are NOT permissions: creatorType (1 Resource / 2 Contact — who uploaded a file does not decide who may read it) and attachmentType (FILE_ATTACHMENT has bytes; URL / FILE_LINK / FOLDER_LINK are links with no downloadable content).

Parent/child conflict — narrower wins. An attachment can hang off a ticket, a ticket note, or a time entry (AttachmentInfo carries ticketID, ticketNoteID and timeEntryID as separate foreign keys, so the parent is unambiguous). Because every attachment resolves internal, an attachment on a public parent — e.g. one hanging off a customer-facing summaryNotes time entry — stays internal. That is deliberate and fail-closed: the conflict can only over-restrict, never leak.

Testing with a Single Ticket First

Before running a full migration you can sync exactly ONE ticket (plus its linked company, primary contact, notes, time entries, and attachments) as a silent import that fires no notifications:

POST /api/v1/bridge/migration-sync/single-ticket
{
  "connection_id": "<your autotask connection id>",
  "autotask_ticket_id": "12345"
}

The response is a verification report showing each record that landed, the visibility decision for every note, any flagged attachments, and a zero_notifications_guaranteed flag. It is idempotent — re-running updates rather than duplicates, and already-synced attachments are not re-downloaded. Admin/owner role required.

Related

• How Ticket Sync Works
• Company Sync
• Sync Logs