Reference · built on requestConnectorWork & ticket management

TOPdesk

Incidents, changes, operators, persons, and assets from a TOPdesk environment through its REST APIs.

Request accessPricing ↗

About

TOPdesk is a service management system used by IT and facilities departments. It records incidents, changes and their activities, the operators and operator groups that handle them, the persons who raise them, and the assets they concern. Each module has its own REST API under /tas/api on your environment's host, with separate incident endpoints for operators and for requesters.

Through Fibric an operator reads incidents as they change, checks each against its target date and operator group, and proposes the next step for a person to approve. Each approval is recorded with what changed, why, and the way back.

This is a reference listing. It documents what Fibric would read from TOPdesk and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Incidents from GET /incidents, with status firstLine, secondLine, or partial and fields such as briefDescription, priority, targetDate, operatorGroup, and processingStatus
  • The progress trail, actions, and requests on an incident, plus its time registrations and attachments
  • Changes and change activities through /operatorChanges and /operatorChangeActivities, with the change calendar and processing status transitions
  • Operators, operator groups, persons, branches, and locations from the Supporting Files API
  • Assets, their templates, links, and assignments from the Asset Management API at /tas/api/assetmgmt
  • SLA definitions and services from /incidents/slas

Proposed actions

  • Target capability: propose assigning an incident to an operator or operator group, or changing its processingStatus, through PATCH /incidents/id/{id}
  • Target capability: propose an action on the incident's progress trail, visible to the caller or hidden from them
  • Target capability: propose escalating an incident from first line to second line through PUT /incidents/id/{id}/escalate
  • Target capability: propose moving a change to its next phase with POST /operatorChanges/{identifier}/processingStatusTransitions
  • Target capability: propose creating an incident with POST /incidents from a signal raised outside TOPdesk

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Triage what the service desk receives

    New firstLine incidents are read with their category, caller, and request text. The operator proposes the operator group and priority, and a person approves before PATCH /incidents/id/{id} runs.

    With Ticket Triage

  • Catch an incident before its target date

    Incidents are polled with targetDate and processingStatus. Those near the SLA deadline with no recent progress-trail action are listed, and the operator proposes an escalation or a reassignment.

    With Breach Watch

  • Keep changes out of a freeze window

    Changes and activities on the change calendar are compared with your freeze windows. Any planned inside one is flagged, and the operator drafts the note to the change manager.

    With Change Freeze

  • Find facilities work that has stalled

    Incidents assigned to facilities operator groups are ranked by age and time on hold. The operator proposes the next action for each, for a person to approve.

    With Work Order Aging

Requirements

  • A TOPdesk environment reachable over HTTPS at its own host, such as customer.topdesk.net
  • An operator or API account in a permission group with read and write rights on Incident Management, and on Change or Asset Management where used
  • An application token for that account; it is shown once at creation and expires after one year by default
  • Agreed category, branch, and operator filters on the account, since they apply to every incident the API returns
Authentication
HTTP Basic authentication with an operator's login name and an application token created under My Settings or on an API account card; the /login/operator endpoint is deprecated.

Limits

  • GET /incidents returns 10 incidents by default, 10,000 at most, and only firstLine and secondLine unless all=true is set
  • The API Explorer lists no webhook or event-subscription API, so incident changes are read by polling sorted on modificationDate
  • Supporting Files endpoints such as /operators and /persons page at most 100 records per request
  • Persons see only their own incidents through /requester/incidents; operator-side reads need an operator account

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request TOPdesk ↗

Questions and answers

Does TOPdesk send webhooks when an incident changes?
Not through the APIs in the developer explorer. The Incident Management API is read with GET /incidents, a FIQL query, and sort=modificationDate:desc, which the connector polls. A Labs-only Task Notifications API can post a custom notification to operators, but it carries no incident payload.
What credential does the connector use?
An application token, not the web login password. An operator creates one under My Settings, or on an API account card when they hold the right permission. It is sent as the HTTP Basic password with the login name, is displayed once, and expires after one year unless you set another date.
Which incident statuses does the API return by default?
Only firstLine and secondLine. Adding all=true to GET /incidents includes partial and archived incidents, and the status enum also carries firstLineArchived, secondLineArchived, and partialArchived. Persons use the separate /requester/incidents endpoints and see only what they raised.
Ask about TOPdesk

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with TOPdesk through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy