Integrations rarely break dramatically. They fade: a key gets regenerated, a server gets upgraded, a certificate expires — and one direction quietly stops talking. Here is the calm way back.
The most common integration story is not a failed setup. It is a setup that worked for months and then, one ordinary week, stopped — no new assets, ticket actions failing, nobody sure when it began. Resist the urge to reinstall anything. Integrations between Endpoint Central and ServiceDesk Plus fail for a short list of boring reasons, and almost all of them are fixed by checking, in order: which direction died, what changed recently, and whether the keys still match.
Everything else depends on this, so be precise. Is inventory still landing in ServiceDesk Plus? Do tickets raised from a PC's agent still arrive? Separately: can a technician still start a remote session or deploy from a ticket?
The first pair tests the Endpoint Central → ServiceDesk Plus direction, authenticated by the key generated in Endpoint Central. The second tests the reverse direction, authenticated by the ServiceDesk Plus technician's API key. One dead direction with the other alive is not a mystery — it is a fingerprint, and it points at one key, one settings screen, one fix.
Integrations are killed by birthdays, not by time. Ask what changed in the window before it died:
Because key mismatch is the most common and cheapest fix, do it early: open the generating console, view or regenerate the key, and paste it freshly into the partner — Endpoint Central's key into the ServiceDesk Plus server settings; the ServiceDesk Plus technician's key into Endpoint Central under Admin → Integrations → ServiceDesk Plus settings.
While you are in those screens, re-read the boring fields: server name, port, protocol. A surprising number of broken integrations are a settings page faithfully pointing at a server that was retired in March. Save, then retest with a live action — a test ticket from an agent, one harmless remote open — not by staring at the saved form.
If keys and addresses are right, check the accounts underneath them. The ServiceDesk Plus technician who owns the API key must still exist, still have login enabled, and still hold SDAdmin privileges. Technicians who lose the Endpoint Central plugin enablement — the Desktop and MDM plugin checkbox on their record — lose the menu and the actions even while sync keeps working, which looks like a partial break and confuses everyone.
Also confirm nobody helpfully tidied up: integration accounts look unused to anyone who does not know what they are, and quarterly account clean-ups are a classic silent killer.
Once it breathes again, spend ten minutes making the next break louder and shorter. Name the integration account so its purpose is unmistakable. Add both products to the same maintenance habit: after upgrading either Endpoint Central or ServiceDesk Plus, run the two-minute integration test the same day — one asset check, one ticket action. Note the key regeneration dates in your admin diary, so future-you checks the obvious suspect first.
An integration tested after every change almost never gets to die quietly for a month.
The full ManageEngine integration — server settings, API keys and live ticket actions, shown step by step.
▶️ Watch Full VideoThat is the ServiceDesk Plus → Endpoint Central direction. Check the ServiceDesk Plus technician API key pasted in Endpoint Central (Admin → Integrations → ServiceDesk Plus settings), that the technician still has SDAdmin rights, and that the technician's Desktop and MDM plugin access is enabled.
Treat it as version drift: verify the server settings survived the upgrade exactly (name, port, protocol), re-paste both API keys, and retest both directions with live actions. If it still fails, note both products' build numbers before contacting support — that is the first thing they will ask.
Add an integration check to your upgrade routine — after any upgrade, patch or certificate change on either server, spend two minutes proving one asset sync and one ticket action. Most silent breaks are discovered by users weeks later simply because nobody ran that test.