REST API known issues and limitations

Monitoring and Logging

For the first revision of the API Service, monitoring and logging in the API-service module are only available as entries in the api-service.log file, downloadable from the UI by system admins. No other auditing, dashboards, metrics, or logs will be available except for the api-service.log.

Reboot of N-central requires token exchange

If the N-central device is rebooted, the application that is using the REST APIs will need to repeat the “User API Token” → “Access Token/Refresh Token” exchange. This is because all key exchanges are conducted in memory for security purposes.

Tasks created through APIs could pile up if not tracked

If a single device extensively uses the scheduled-tasks/direct API call (with tens of thousands of invocations), it will accumulate these task executions in the database. A side effect of this action is that visiting "Device → Tools → Task Execution" will result in long loading times as we fetch the entire list for display in the UI.

Error handling and communication

In a few cases, the error response from N-central's core engine appears as an "Error Message" attached to a 200 OK response rather than an error number in the HTTP response. We suggest always checking for an “error message” field in the response to catch these occurrences, although these are expected to be rare.

Rate limited endpoints

To prevent N-central servers from being overwhelmed by too many API calls at once, which could cause a DDOS (Distributed Denial Of-Service) attack, the REST API endpoints have concurrency rate limits. This means that only a certain number of calls can be processed simultaneously for each endpoint. The limit varies from 1 to 50 concurrent calls, depending on how resource intensive the endpoint is. When the limit is reached, the server will send back a 429 TOO MANY REQUESTS HTTP response. For ALL the endpoints, the caller should be able to handle this error and try again after waiting.

Current limits default: 50 endpoints: GET /api: 50 GET /api/access-groups: 5 GET /api/access-groups/{accessGroupId}: 5 GET /api/appliance-tasks/{taskId}: 5 GET /api/auth: 50 POST /api/auth/authenticate: 50 POST /api/auth/refresh: 50 GET /api/auth/validate: 50 GET /api/custom-psa: 50 GET /api/custom-psa/tickets: 50 POST /api/custom-psa/tickets/{customPsaTicketId}: 3 GET /api/customers: 5 GET /api/customers/{customerId}: 5 GET /api/customers/{customerId}/registration-token: 5 GET /api/customers/{customerId}/sites: 5 POST /api/customers/{customerId}/sites: 3 GET /api/device-filters: 5 GET /api/devices: 5 GET /api/devices/{deviceId}: 50 GET /api/devices/{deviceId}/assets: 50 GET /api/devices/{deviceId}/assets/lifecycle-info: 1 PUT /api/devices/{deviceId}/assets/lifecycle-info: 1 PATCH /api/devices/{deviceId}/assets/lifecycle-info: 1 GET /api/devices/{deviceId}/custom-properties: 5 GET /api/devices/{deviceId}/custom-properties/{propertyId}: 5 PUT /api/devices/{deviceId}/custom-properties/{propertyId}: 5 GET /api/devices/{deviceId}/scheduled-tasks: 30 GET /api/devices/{deviceId}/service-monitor-status: 5 GET /api/devices/{deviceId}/maintenance-windows: 30 POST /api/devices/maintenance-windows: 1 DELETE /api/devices/maintenance-windows: 1 PUT /api/devices/maintenance-windows: 1 GET /api/health: 50 GET /api/org-units: 5 GET /api/org-units/{orgUnitId}: 5 GET /api/org-units/{orgUnitId}/access-groups: 5 POST /api/org-units/{orgUnitId}/access-groups: 3 GET /api/org-units/{orgUnitId}/active-issues: 3 GET /api/org-units/{orgUnitId}/children: 5 GET /api/org-units/{orgUnitId}/custom-properties: 5 GET /api/org-units/{orgUnitId}/custom-properties/device-custom-property-defaults/{propertyId}: 5 GET /api/org-units/{orgUnitId}/custom-properties/{propertyId}: 5 PUT /api/org-units/{orgUnitId}/custom-properties/{propertyId}: 3 GET /api/org-units/{orgUnitId}/devices: 5 POST /api/org-units/{orgUnitId}/device-access-groups: 3 GET /api/org-units/{orgUnitId}/job-statuses: 5 PUT /api/org-units/{orgUnitId}/org-custom-property-defaults: 3 GET /api/org-units/{orgUnitId}/org-custom-property-defaults/{propertyId}: 5 GET /api/org-units/{orgUnitId}/registration-token: 5 GET /api/org-units/{orgUnitId}/user-roles: 5 POST /api/org-units/{orgUnitId}/user-roles: 3 GET /api/org-units/{orgUnitId}/user-roles/{userRoleId}: 5 GET /api/org-units/{orgUnitId}/users: 5 GET /api/scheduled-tasks: 50 POST /api/scheduled-tasks/direct: 30 GET /api/scheduled-tasks/{taskId}: 50 GET /api/scheduled-tasks/{taskId}/status: 50 GET /api/scheduled-tasks/{taskId}/status/details: 5 GET /api/server-info: 50 GET /api/server-info/extra: 5 POST /api/server-info/extra/authenticated: 3 GET /api/service-orgs: 5 POST /api/service-orgs: 3 GET /api/service-orgs/{soId}: 5 GET /api/service-orgs/{soId}/customers: 5 POST /api/service-orgs/{soId}/customers: 3 GET /api/sites: 5 GET /api/sites/{siteId}: 5 GET /api/sites/{siteId}/registration-token: 5 GET /api/standard-psa: 50 POST /api/standard-psa/{psaType}/credential: 3 GET /api/users: 5

PSAs operations

Operations including create, reopen, resolve, and retrieve details are limited exclusively to custom PSA integrations. These operations are not available for managed PSA services, such as ConnectWise (CW), AutoTask (AT), TigerPaw, etc.

The PSACredentialsValidate (/api/standard-psa/{standardPsaId}/credential) operation is compatible only with TigerPaw(3.0). It cannot be used with other PSA integrations, managed or custom.

(v2024.6) (Fixed in v2025.3.1.9)lastApplianceCheckinTime available only in /api/devices/{deviceid}

The response object for the /api/devices endpoint suggests that lastApplianceCheckinTime is available in each device returned. This is incorrect. The lastApplianceCheckinTime field is only available in the /api/devices/{deviceid} endpoint. This means that to get the field a separate API call with that device id needs to be made.

NOTE: This issue has been addressed in v2025.3.1.9. The lastApplianceCheckinTime field is now available in this endpoint

/api/devices/{deviceId}/assets Does Not Return results for Probes. Returns 404 instead

Probes show amongst the list when the /api/devices endpoint is used to fetch the list of devices. That's because probes are a type of device and therefore appear in the list. However probes to not have any assets associated with them. This is reflected in the UI as well. There are no assets to be viewed for probes. So when the /api/devices/{deviceid}/assets endpoint is used with the ID of a probe as the deviceID the endpoint returns 404. This is expected behaviour.

Bug in Active Issues -> Both _extra.deviceClassValue and _extra.deviceClassLabel, are always null

When using the active issues endpoint the list includes both _extra.deviceClassValue and _extra.deviceClassLabel fields but they are both null. This has been confirmed as a bug and added to the backlog.

Password of API User account expires in 90 days

The API User that is used for API calls is created the same way other users are created. This results in a password associated with this user that follows the password expiration policies of the server which by default is every 90 days. Even though the API User does not need and use that password, the expiration causes the API calls to fail because the user is considered expired. If you have been using the API user without a problem for a while and suddenly you are getting 500 INTERNAL ERRORs , the most likely cause is this.

To fix this problem, all you need to do is update the password for the API User only. In the "Edit User" page, just add a new password and press save.

It is recommended that you set a reminder to alert you to reset the password every 80 days so the problem is prevented ahead of time.

Null values in lastLoggedInUser and stillLoggedIn fields for /api/devices/{deviceId} endpoint

When using the /api/devices/{deviceid} endpoint to get information about a specific device, the lastLoggedInUser and stillLoggedIn fields are always null. This is an underlying non-trivial bug that will be fixed in the future. The only workaround known so far is to use the /api/devices endpoint to get a list of all devices, look for the device and extract the fields from that output ( the values are NOT null in the list output )