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. 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 using the REST APIs will repeat the “Secret” → “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.

No bulk scheduled-tasks created through API Service

Our goal for the first version was to cover direct support task creation. In the first version, each task created through the API Service targets a single device and immediately runs the script. Further task types, such as profile-based or scheduled tasks, will be included in future phases.

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 3 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.

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

When using the /api/devices/{deviceid} endpoint to retrieve 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. A suggested workaround 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, as the values are NOT null in the list output.