ManageEngine ServiceDesk Plus

Info-Tech needs the exact ServiceDesk Plus base URL and deployment type before credentials can be validated. Cloud customers must also use the correct regional API domain.

1. Confirm deployment type. Identify whether the instance is ServiceDesk Plus Cloud or ServiceDesk Plus on-premises.
2. Record the base URL. Examples: https://sdpondemand.manageengine.com, https://servicedeskplus.ca, or https://servicedesk.yourcompany.com. Do not include extra navigation paths unless your tenant specifically requires a portal path such as /app/<portal>/api/v3.
3. For Cloud, confirm the API domain. Use the customer data center/API domain returned by OAuth token handling or confirmed in the ServiceDesk Plus Cloud documentation. Do not hardcode the United States domain for all customers.
4. For on-premises, confirm network reachability. The integration runtime must be able to reach the ServiceDesk Plus server over HTTPS. If the instance is internal-only, a network path or allowlist may be required.

A dedicated identity makes access auditable and easy to revoke. It also avoids breaking the connection when a human employee changes roles or leaves the organization.

1. Create or select a dedicated account. Suggested name: cioanalytics or Info-Tech CIOAnalytics.
2. Use a controlled email address. Suggested email: cioanalytics@yourcompany.com.
3. For on-premises API-key setup, ensure the account has login permission. ManageEngine on-premises API keys are generated for users or technicians with login permission.
4. Do not use a broad administrator account unless required by local policy. The preferred model is a purpose-built read-only role or technician profile.
5. Keep the account active. If the user or technician is disabled, the associated token or API key may stop working.

Grant only the permissions needed to read ServiceDesk Plus request data and supporting reference metadata. The Customer Data Store does not require write-back access.

1. Grant read access to requests. The integration must be able to list and read request records and request fields.
2. Grant read access to supporting metadata. Include statuses, priorities, modes, request types, levels, categories, subcategories, items, sites, departments, groups, technicians/users, and SLA metadata.
3. Grant read access to request worklogs. Worklogs are needed for technician work effort reporting.
4. Grant read access to satisfaction/survey responses only if enabled. Survey data is conditional and should be validated tenant by tenant.
5. Do not grant create, edit, delete, or administrative write permissions. The integration is read-only.
6. Confirm field-level visibility. Some tenants restrict technician email, requester email, site, department, SLA, or survey fields. These restrictions can cause nulls even when the request endpoint itself is readable.

Choose the authentication setup that matches the customer's ServiceDesk Plus deployment.

1. For ServiceDesk Plus Cloud, use Zoho OAuth 2.0. Register or authorize an OAuth client using the customer-approved flow. Use read-only scopes such as SDPOnDemand.requests.READ and read access to setup/reference metadata such as SDPOnDemand.setup.READ, if required for the selected endpoints.
2. For Cloud API calls, use the OAuth access token header. The header format is:

   Authorization: Zoho-oauthtoken YOUR_ACCESS_TOKEN

3. For ServiceDesk Plus on-premises, generate an API key/authtoken. Create the key for the dedicated integration technician or user. Select an expiration policy approved by the customer's security team.
4. For on-premises API calls, use the API key/authtoken header. The common v3 header format is:

   authtoken: YOUR_API_KEY

5. Store secrets securely. OAuth client secrets, refresh tokens, API keys, and service-account passwords must be entered only through the approved Info-Tech submission flow.

Before submitting credentials, confirm the integration identity can read the required ServiceDesk Plus API resources.

1. Test a Cloud request list read. Replace the domain and token with customer values. If your tenant uses a portal path, include /app/<portal> before /api/v3.

   curl -G "https://sdpondemand.manageengine.com/api/v3/requests" \
     -H "Accept: application/vnd.manageengine.sdp.v3+json" \
     -H "Authorization: Zoho-oauthtoken YOUR_ACCESS_TOKEN" \
     --data-urlencode 'input_data={"list_info":{"row_count":1}}'

2. Test an on-premises request list read. Replace the base URL and API key with customer values.

   curl -G "https://your-sdp-server.example.com/api/v3/requests" \
     -H "Accept: application/vnd.manageengine.sdp.v3+json" \
     -H "authtoken: YOUR_API_KEY" \
     --data-urlencode 'input_data={"list_info":{"row_count":1}}'

3. Confirm a successful response. A successful response should include a response_status success value and a request list or an empty but authorized result.
4. Test API-verified supporting data. Confirm the same credential can read representative request details and request worklogs. Confirm that reference values embedded on requests are populated for status, priority, mode, request type, level, category, subcategory, item, requester, technician, group, department, site, and SLA.
5. Do not validate survey data as a standard required endpoint. Satisfaction/survey responses are conditional and must be validated separately with the final connector or customer-approved export/API path before they are included in onboarding.
6. Capture failures by code and body. ManageEngine responses often include both an HTTP status and a response_status object. Keep both when troubleshooting.