BACK TO HELP CENTER

Shufti - 400 Status Code (Client Error)

400 Status Code (Client Error)

The request could not be understood by the server due to malformed syntax. The client SHOULD
NOT repeat the request without modifications.

It is a general error when fulfilling the request would cause an invalid state. Domain validation errors,
missing data, etc. are some examples.

401 (Unauthorized)

The request requires user authentication. The response MUST include a WWW-Authenticate header
field containing a challenge applicable to the requested resource. The client MAY repeat the request
with a suitable Authorization header field. If the request already included Authorization credentials,
then the 401 response indicates that authorization has been refused for those credentials. If the 401
response contains the same challenge as the prior response, and the user agent has already
attempted authentication at least once, then the user SHOULD be presented the entity that was given
in the response, since that entity might include relevant diagnostic information. HTTP access
authentication is explained in “HTTP Authentication: Basic and Digest Access Authentication“.

402 (Invalid Request)

This status code occurs when the request has missing parameters. In the API requests, generally,
there are some compulsory and some optional parameters. In case one of the compulsory parameters
is missing in the API request, a 402 error code is returned.

403 (Forbidden)

The server understood the request but is refusing to fulfil it. Authorization will not help and the
request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to
make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in
the entity. If the server does not wish to make this information available to the client, the status code
404 (Not Found) can be used instead.

404 (Not found)

The server has not found anything matching the Request-URI. No indication is given of whether the
condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server
knows, through some internally configurable mechanism, that an old resource is permanently
unavailable and has no forwarding address. This status code is commonly used when the server does
not wish to reveal exactly why the request has been refused, or when no other response is applicable.

409 (Conflict)

The request could not be completed due to a conflict with the current state of the resource.
This code is only allowed in situations where it is expected that the user might be able to resolve the
conflict and resubmit the request. The response body SHOULD include enough information for the
user to recognize the source of the conflict. Ideally, the response entity would include enough
information for the user or user agent to fix the problem; however, that might not be possible and is
not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being
used and the entity being PUT included changes to a resource which conflict with those made by an
earlier (third-party) request, the server might use the 409 response to indicate that it can’t complete
the request. In this case, the response entity would likely contain a list of the differences between the
two versions in a format defined by the response Content-Type.

429 (Too Many Requests)

This status code is returned in case too many requests are sent to the server. For the production
account, Shufti allows 60 requests per min. Similarly, for the test environment, Shufti allows 3
requests per minute. This limit is per IP. In case the user exceeds this limit, a 429 status code appears.