UpToDate® Digital Architect
Status Codes, Errors, and Rate Limits
UpToDate Digital Architect API responses use HTTP status codes to indicate success or failure, following standard REST API practices.
Successful Requests
Requests that are successful return a status code from the 2xx or 3xx series of status codes.
200 OK
The request was successful. Most endpoints return a response body for a successful request, typically JSON.
302 Found
The request was successful, and the response is a redirect to the resource specified in the Location HTTP header. This is a standard redirect response, and is used in endpoints that return a file intended to be consumed directly by a web browser, instead of a JSON response.
Failed Requests
Requests that are not successful return a status code from the 4xx or 5xx series of status codes.
400 Bad Request
The request failed validation. Examples include a required query parameter was not supplied or an unrecognized query parameter value was used.
401 Unauthorized
The request failed authentication. This indicates credentials were invalid or missing from the request. This response is returned if any of the following conditions are met:
A subscription key was used but it is invalid and was never created by Wolters Kluwer.
A subscription key was used but is deactivated. In this case it was created by Wolters Kluwer but is deactivated and can no longer be used.
A secure URL with a JWT access token was used but the JWT token is invalid, for example it may have expired or have a bad signature.
Multiple credentials were used, for example a subscription key and a JWT token.
403 Forbidden
The request failed authorization. This indicates a request was made to an endpoint for which the client is not authorized, or a request was made for content for which the client is not authorized.
404 Not Found
A request was made for a content item that does not exist. Typically this indicates the identifier used in the request does not refer to a valid content item.
429 Too Many Requests
The request was rejected due to exceeding the rate limit. The client should retry the request. See the Rate Limits section below for more details.
500 Internal Server Error
The request failed due to an internal server error.
503 Service Unavailable
The request failed due to a service error. This generally indicates an intermittent error, such as timeout, and the client should retry the request.
Failed Request JSON Response
Most failed requests return a JSON response that provides more detail on the failure. The codes and messages within the response are provided for informational purposes only, are subject to change in a way that is not backwards compatible, and are not intended to be used in client code.
The following is an example response body for a 400 Bad Request response.
Rate Limits
The UpToDate Digital Architect APIs enforce a rate limit, which is designed to ensure fair usage of our API resources while maintaining optimal performance for all clients. By following these rate limiting guidelines, you can make the most of our API without causing disruptions to yourself or other clients.
The rate limit for all API endpoints id 40 requests/second. If possible, consider throttling your API requests to stay under this limit. If you believe your use case requires a higher rate limit, please contact Wolters Kluwer to discuss your requirements.
When you exceed the rate limit, you will receive a 429 Too Many Requests HTTP status code. When you get this response, you should retry your request using exponential backoff and retry logic. The following links from major cloud providers discuss their best practices for retries with exponential backoff.
Google - Example exponential backoff algorithm: https://cloud.google.com/memorystore/docs/redis/exponential-backoff
Amazon - Retry behavior with exponential backoff in AWS SDK: https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html
Microsoft - Implement retries with exponential backoff: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/implement-retries-exponential-backoff