Most failed integrations were doomed before the first setting was touched. Twenty minutes of checking on both servers is the difference between a smooth setup and a long night of guessing.
The integration between Endpoint Central and ServiceDesk Plus is genuinely a short job — server details, two API keys, a few checkboxes. So why do people lose evenings to it? Because the failure is almost never in the integration screens. It is in the prerequisites nobody checked: an account without the right privilege, a certificate one server refuses to trust, a name that does not resolve. Work through this list first, and the setup itself becomes the easy part it is supposed to be.
You will configure server-level settings in both products, so you need administrator access in Endpoint Central and in ServiceDesk Plus. The ServiceDesk Plus side goes further: the API key used by the integration belongs to a technician, and ManageEngine's own steps specify that this technician needs SDAdmin privileges with login enabled.
If your ServiceDesk Plus admin is a different person, get them involved before you start — especially because of one documented quirk: an administrator cannot enable the Endpoint Central menu for their own account. A second admin has to do it. Discovering that at the last step, alone, at 7 pm, is a rite of passage you can skip.
The lazy route is generating the API key under your own technician account. It works — until you change your password, leave the team, or your account gets locked, and the integration quietly dies with it.
The professional route: create a dedicated technician in ServiceDesk Plus for the integration, with login enabled and SDAdmin rights, used for nothing else. Name it so the next administrator understands it at a glance. Its API key is then the integration's identity — stable, auditable, and revocable without touching any human's account. The same discipline applies on the Endpoint Central side for the key generated there.
Each server will call the other using three facts: server name, port, communication protocol. All three must describe reality. If Endpoint Central runs on HTTPS, entering HTTP in ServiceDesk Plus fails. If the name you type does not resolve from the other server's network position, it fails. If one server presents a certificate the other does not trust, it fails — ManageEngine's own FAQ calls out exactly this error when Endpoint Central runs in HTTPS mode.
Test it before the setup: from each server, open the other product's console in a browser using the exact name and protocol you plan to enter. If a human cannot reach it cleanly, the integration will not either.
Integration is not just a pipe — it files things. Asset data lands in the ServiceDesk Plus CMDB against sites and assets, and on MSP-style and multi-site setups ManageEngine is explicit: the site name in Endpoint Central should match the remote office name in ServiceDesk Plus, customer credentials should match on both sides, and the hierarchy of computers should be the same in both products.
Even on a single-site install, glance at how your computers are organised in Endpoint Central before syncing a full inventory into a help desk that has never held it. Ten minutes of alignment now beats a CMDB full of duplicates later.
The integration lets you choose what to integrate: asset data, help desk requests, software deployment, remote control worklogs, the full UI menu. Switching on everything at once is how a help desk gets flooded with auto-generated tickets for every detected change on the network.
Decide deliberately: most teams start with asset data plus the ticket-side actions (remote control and deployment), prove the value for a week, then add event-based auto-tickets for the few events that genuinely need a human — prohibited software and expired licences are the usual first two.
The full ManageEngine integration — server settings, API keys and live ticket actions, shown step by step.
▶️ Watch Full VideoYou can, but you should not. Password changes, account lockouts and staff exits all break integrations tied to a person's login. A dedicated SDAdmin technician created only for the integration is stable, auditable and safe to re-key.
Each server must be able to reach the other using the server name, port and protocol you configure. They do not need to be on the same machine, but firewalls, name resolution and certificate trust between them must all work — test by opening each console from the other server first.
Keep both products reasonably current and update them in a planned way. Version gaps are a common cause of odd integration behaviour, and after any upgrade of either product, re-test the integration the same day instead of discovering a silent break next month.