Skip to main content
Starter ⭐
September 7, 2026

Topdesk APIs Q

  • September 7, 2026
  • 6 replies
  • 18 views

Hi Community,

I really like the idea of seeing assets assigned to a person from the Person Record this is the best feature that caught my eye so far. Definitely going to save a lot of headaches during onboarding and offboarding.

I have a few technical questions regarding automated assignments and Incident creation via the API:

  1. Automated Asset Assignment: Is there an OOB way to automatically assign an asset (like a laptop) to a person once a service request is fulfilled?

  2. Mandatory Fields in the API: I set up an API account, granted the required permission/operator group, and generated an application token (GET requests are working as expected). When attempting to POST a new incident, the ticket management shows only “brief description”as required. However, when creating an incident manually in the UI, several other fields are highlighted in red as mandatory. Where are these validation rules defined? 

  3. DataDict vs. API Naming: I noticed the field names in the DataDict don't match the REST API JSON payload keys. Is there a standard mapping table or guide available for translating DataDict database names to API endpoint fields?

  4. Integration Field Mapping: If we integrate another system to create incidents in TOPdesk, does TOPdesk offer a built in field mapping table, or do we need to handle that in the payload?

Thanks in advance.

6 replies

Joost Oostindie
Contributor
September 8, 2026

Hi ​@Ayman,

  1. There is no generic automation that assigns an asset to a person when a request is fulfilled. Typically this is handled either manually by the operator, through an Action Sequence/workflow, or via an integration/API process.
    Using the API would probably be the oob solution to do this automatically. The way it works depends on your process of hardware delivery, assignment, signing and optional suppliers. It can be configured accordingly.
     
  2. The API only validates the fields required by the endpoint. Additional mandatory fields shown in the UI are usually configured in the module settings (i.e. Settings → Module Settings → Call Management). See docs.topdesk.com/en/making-fields-mandatory.html
     
  3. This is correct. The API uses database field names, which do not always match the labels shown in the UI. The DataDict is the best reference for understanding the relationship between UI and database fields. Also TOPdesk developers might offer some more insight into this (developers.topdesk.com)
     
  4. TOPdesk expects data in the format required by the API endpoint. In most integrations, field mapping is handled in the source system, middleware, or integration platform.
    TOPdesk likewise offers field mapping tables within the action sequence that you can configure to handle field mapping for different fields, so it's not necessary to handle this in the payload.

Hope this helps! I'd also recommend creating an incident manually and comparing it with the API GET response. That often makes it easier to determine which fields your integration should populate.
If you want to be able to test different API calls separately, I would suggest using Postman if you don't already.

Joost mag het weten, jij ook!
AymanAuthor
Starter ⭐
September 8, 2026

Hello ​@Joost Oostindie,
Thanks for your feedback.

1- Is clear.

2- Is there a way to access/update fields required at the endpoint level and define auto assignment rules?
only “brief description” “request” are mandatory in the UI
 


I notice the caller is not populated automatically in incident creation, from the logged in user, is is the OOB behaviour of TOPdesk? this justifies the need of ID from the API

 

 

 

3- Is clear

4- Is clear

 

That’s exactly what I am doing, or triggering POST requests and discovering what the endpoints is trying to validate everytime. This is the reason reason I wish some quick access to that validation would be available.

Thanks again Joost

Joost Oostindie
Contributor
September 8, 2026

At the endpoint level it's not. Within the module settings you can only configure mandatory fields within the operator section. Via API you'd still be able to create an incident without filling those mandatory fields you configured, but the first time someone edits the incident the mandatory fields need to be filled manually.

It's probably easiest to define them within the API, you can find all of the possible endpoints to fill with the post here: Incident Management | TOPdesk API - POST Incidents

Caller is indeed not populated automatically, but can also be defined within the POST request.

You're most welcome, hope this answers your questions and good luck with the testing!

Joost mag het weten, jij ook!
AymanAuthor
Starter ⭐
September 8, 2026

We will end with this ​@Joost Oostindie  I promise 😄, currently I am getting the callers IDs through API, let’s say in the absence of API or access to the database, where would you get ID information. As far as I looked in both person and operator records the ID field is absent.

Joost Oostindie
Contributor
September 8, 2026

Hi ​@Ayman that's okay, ask away!
The ID field is indeed only available through the API or database, so there's not really another way to get this information. It is static, so in case of the same caller/operator you can keep using the same ID and map this in a variable within the action sequence for example.
When this is not the case and the caller/operator changes, you always have to add the step to GET this record within your action sequence to reference back to that.

Aside from that, in the past years I've worked with TOPdesk I've only experienced API downtime once or twice, for a very short instance. And in these cases action sequences in general do not work.
So I think I would dismiss this possibility as almost non existent, especially when keeping in mind the uptime % that TOPdesk has in general.

Joost mag het weten, jij ook!
AymanAuthor
Starter ⭐
September 8, 2026

That’s an interesting feedback, thanks a lot for the clarification Joost. See you in another topic!