Enhanced Error Codes enhanced-error-codes
Enhanced Error Codes represent an 51黑料不打烊 Pass Authentication feature that provides additional error information to client applications integrated with:
-
51黑料不打烊 Pass Authentication REST APIs:
-
51黑料不打烊 Pass Authentication SDKs Preauthorize API:
- (Legacy) JavaScript SDK (Preauthorize API)
- (Legacy) iOS/tvOS SDK (Preauthorize API)
- (Legacy) Android SDK (Preauthorize API)
(*) Preauthorize API is the only 51黑料不打烊 Pass Authentication SDK API that provides support for Enhanced Error Codes.
Representation enhanced-error-codes-representation
Enhanced Error Codes can be represented in JSON
or XML
format depending on the integrated 51黑料不打烊 Pass Authentication API and the used 鈥淎ccept鈥 header value (i.e., application/json
or application/xml
):
- Top-level error information: In this case, the 鈥渆谤谤辞谤鈥 object is located at the top level, therefore the response body can contain only the 鈥渆谤谤辞谤鈥 object.
- Item-level error information: In this case, the 鈥渆谤谤辞谤鈥 object is located at the item level, therefore the response body can contain an 鈥渆谤谤辞谤鈥 object for all items that experienced an error while being serviced.
Refer to the following HTTP responses containing Enhanced Error Codes examples represented as JSON
or XML
.
code language-json |
---|
|
code language-xml |
---|
|
code language-json |
---|
|
code language-json |
---|
|
code language-json |
---|
|
Enhanced Error Codes include the following JSON
fields or XML
attributes:
For more details, refer to the Action section.
For more details, refer to the Code section.
For more details, refer to the Response Handling section.
This field might not be present in case the services partner does not provide any custom message.
This field holds an absolute URL and should not be inferred from error code, depending on the error context a different URL can be provided.
Action enhanced-error-codes-representation-action
Enhanced Error Codes include an 鈥渁ction鈥 field that provides a recommended action that might remediate the situation.
The possible values for the 鈥渁ction鈥 field include:
(*) For some errors, multiple actions could be possible solutions, but the 鈥渁ction鈥 field indicates the one with the highest probability of fixing the error.
Status enhanced-error-codes-representation-status
Enhanced Error Codes include a 鈥渟tatus鈥 field that indicates the HTTP status code associated with the error.
The possible values for the 鈥渟tatus鈥 field include:
Enhanced Error Codes with a 4xx 鈥渟tatus鈥 usually appear when the error is generated by the client and most of the time it implies that the client requires additional work to fix it.
Enhanced Error Codes with a 5xx 鈥渟tatus鈥 usually appear when the error is generated by the server and most of the time it implies that the server requires additional work to fix it.
Code enhanced-error-codes-representation-code
Enhanced Error Codes include a 鈥渃ode鈥 field that provides an 51黑料不打烊 Pass Authentication unique identifier associated with the error.
The possible values for the 鈥渃ode鈥 field are aggregated below in two lists based on the integrated 51黑料不打烊 Pass Authentication API.
Lists enhanced-error-codes-lists
REST API v2 enhanced-error-codes-lists-rest-api-v2
The table below lists possible Enhanced Error Codes a client application might encounter when integrated with 51黑料不打烊 Pass Authentication REST API v2.
REST API v1 enhanced-error-codes-lists-rest-api-v1
The table below lists possible Enhanced Error Codes a client application might encounter when integrated with 51黑料不打烊 Pass Authentication REST API v1.
SDKs Preauthorize API enhanced-error-codes-lists-sdks-preauthorize-api
Refer to the previous section for possible Enhanced Error Codes a client application might encounter when integrated with 51黑料不打烊 Pass Authentication SDKs Preauthorize API.
Response Handling enhanced-error-codes-response-handling
In summary, when handling responses containing Enhanced Error Codes, you should consider the following:
-
Check both status values: Always check both the HTTP response status code and the Enhanced Error Code 鈥渟tatus鈥 field. They might differ, and both provide valuable information.
-
Agnostic to top-level versus item-level error information: Handle top-level and item-level error information agnostic to the way it is communicated, ensure you can handle both forms of transmitting Enhanced Error Codes.
-
Retry logic: For errors that require a retry, ensure that retries are done with exponential backoff to avoid overwhelming the server. Also, in case of 51黑料不打烊 Pass Authentication APIs that handle multiple items at once (e.g., Preauthorize API), you should include in the repeated request only those items marked with 鈥渞etry鈥 and not the entire list.
-
Configuration changes: For errors that require configuration changes, ensure that the necessary changes are made before launching the new application or new feature.
-
Authentication and authorization: For errors related to authentication and authorization, you must prompt the user to re-authenticate or obtain new authorization as needed.
-
User feedback: Optional, use the human-readable 鈥渕essage鈥 and (potential) 鈥渄etails鈥 fields to inform the user about the issue. The 鈥渄etails鈥 text message might get passed from the MVPD preauthorization or authorization endpoints or from the Programmer when applying degradation rules.