Can APIGEE display an error page in a webpage?

Hi guys, just a simple question. I have an api proxy which is connected to an webpage. The proxy has various policies such as APIKey,Quota. Now if I surpass the quota limit my webpage just hangs ups, it doesn't show any error.

But in trace we can see the Quota error. How can I display an error page in my webpage when quota surpasses it's limit.

Another scenario can be like, i have regenerated my API key so ideally my webpage wouldn't work. It just hangs up. I want the webpage to display some error notification.

is there any way that we can do that from APIGEE?

Solved Solved
0 3 313
2 ACCEPTED SOLUTIONS

It will depend on the implementation details on the calling side. If the client doesn't understand the response code from a quota error (I think 429? Haven't confirmed) then you can either change the response from the Apigee proxy to something the client does understand, or you can modify the logic of the client to deal with the error response code. In my opinion, you should stick to standard responses from the API (at the very least the 200/400/500 set) and implement the error handling on the client side, rather than converting the error to something like a 200 that the client would have an easier time displaying.

View solution in original post

Not applicable

Hi @Barahalikar Siddharth,

Please refer to the fault handling section in the Apigee documentation to learn more. Each Policy type defines a set of 'error codes' and all Policy errors have the same format. Using the 'error codes' of the Quota Management Policy that are present in the Policy error, you can define a custom fault handling policy that responds back with appropriate information to the client.

As noted in the Quota Management Policy documentation, the default Apigee Edge configuration returns an HTTP status code of 500 (Internal Server Error), but can be configured to return an HTTP status code of 429 (Too Many Requests) for all requests that exceed a rate limit set by a Quota policy.

And as @Carlos Eberhardt mentions in his reply above, the client should be implemented such that it handles the error response based upon the HTTP response code and displays relevant information from the error payload to the user.

View solution in original post

3 REPLIES 3

It will depend on the implementation details on the calling side. If the client doesn't understand the response code from a quota error (I think 429? Haven't confirmed) then you can either change the response from the Apigee proxy to something the client does understand, or you can modify the logic of the client to deal with the error response code. In my opinion, you should stick to standard responses from the API (at the very least the 200/400/500 set) and implement the error handling on the client side, rather than converting the error to something like a 200 that the client would have an easier time displaying.

Not applicable

@Siddharth I will suggest you use fault handling (in attached faults) and try to capture the code and translate it to 4xx error which matches to the proxy error.

You can get the relevant videos in section 7.

Not applicable

Hi @Barahalikar Siddharth,

Please refer to the fault handling section in the Apigee documentation to learn more. Each Policy type defines a set of 'error codes' and all Policy errors have the same format. Using the 'error codes' of the Quota Management Policy that are present in the Policy error, you can define a custom fault handling policy that responds back with appropriate information to the client.

As noted in the Quota Management Policy documentation, the default Apigee Edge configuration returns an HTTP status code of 500 (Internal Server Error), but can be configured to return an HTTP status code of 429 (Too Many Requests) for all requests that exceed a rate limit set by a Quota policy.

And as @Carlos Eberhardt mentions in his reply above, the client should be implemented such that it handles the error response based upon the HTTP response code and displays relevant information from the error payload to the user.