| Note |
|---|
The content of this page applies to all the methods of MailUp REST API except for the Transactional APIs, which do not use OAUTH 2.0 |
| Note | ||
|---|---|---|
| ||
From March 2018, MailUp has introduced the HTTP 429 (Too many requests) status code; it replaces the old 403 (Forbidden) status code. |
Before you start
MailUp REST API follows OAuth 2.0 specification and authorizes only the applications that specify a pair of valid access keys ("Client ID" and "Client Secret") in the authentication process.
...
Anyway, if you are not familiar with any of the programming language of our samples, or if you want to know more, you can have a look at the following chapter and also at the pages it refers tosection below.
...
Technical reference
Authorization and authentication
...
In case of successful access to the requested resource, an HTTP 200 status code is returned, along with requested data.
Should an error occur (e.g. caused by malformed request, invalid token, frequency call restrictions or user access privilege limitations), the following error codes are returned:
- HTTP 400 (Bad request): malformed request malformed, or missing one or more parameters.parameters. In case of invalid or malformed authorization token (either refresh token or access token), a proper description message is also returned.
- HTTP 401 (Unauthorized): token expired , revoked, malformed or invalid for any other reasonor revoked token.
- HTTP 403 (Forbidden): the application is requesting a resource which is not in the scope of the impersonated user.
- HTTP 429 (Too many requests): it is returned in case of too many requests per second on a single API resource.
- HTTP 500 (Internal error): returned in case of any resource server internal problem.
- HTTP 503 (Service unavailable): temporary error. The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.
OAuth v2 error codes and error descriptions are returned either as a detail part of the raised fault or as a header parameter as stated in the Bearer token documentation.
...