Troubleshoot errors in the error code table

Causes

The HTTP schema in the request is invalid.

Each API supports a specific HTTP schema. API providers can configure an API to allow HTTP only, HTTPS only, or both.

API unsupport the channel: An HTTP request was sent to an API that supports only HTTPS.

API unsupport the channel: An HTTPS request was sent to an API that supports only HTTP.

Solutions

API unsupport the channel: Use HTTPS instead of HTTP to call the API.

API unsupport the channel: Use HTTP instead of HTTPS to call the API.

Causes

The signature provided by the client does not match the server-side signature.

Solutions

When signatures do not match, API Gateway returns the server-side StringToSign in the X-Ca-Error-Message response header.

StringToSign contains the string used to calculate the signature before a request is sent. For more information, see Use digest authentication to call an API.

Compare your local StringToSign with the one returned in the response. If you used the official demo, retrieve the StringToSign from the signature calculation tool class.

HTTP response headers do not support line breaks, so line breaks in StringToSign are removed from the response. Account for this difference when comparing strings.

If the client-side and server-side strings match, verify that the AppKey and AppSecret are valid. For example, check whether they contain extra spaces.

Causes

The HTTP method, path, or environment (X-Ca-Stage) in the request is invalid.

For example, the request targets an API in the testing environment, but the API has not been published in that environment.

Note:

• If you do not specify an environment in your request, the request is sent to the production (RELEASE) environment by default.

• If you modify an API definition, you must republish the API for the changes to take effect. This error commonly occurs when the API path is changed but the API is not republished.

Solutions

Verify the following three factors in your request: HTTP method, path, and environment.

1. Use the same HTTP method as the API definition. For example, if an API requires POST, do not send a GET request.

2. Use the correct request path. If you own the API, republish it after any modifications.

3. Specify the environment in which you want to call the API. Use the X-Ca-Stage header in your request. Valid values: TEST, PRE, and RELEASE, which indicate the test environment, staging environment, and production environment respectively. If you do not specify the header, your request is sent to the production environment by default.

Causes

The application is not authorized to call the API.

Solution

Try the following solutions:

1. If you created the API, create an application in the API Gateway console and authorize it to call the API. An application is required even for testing your own API.

2. If you purchased the API, check the application details page for the list of authorized APIs. If the target API is not listed, request authorization.

3. If the API belongs to a partner, contact the partner for authorization. Provide your application ID (AppId) so the partner can authorize your application.

4. Authorizations are environment-specific. An application authorized in one environment cannot call the same API in a different environment.

5. Verify that you are using the correct application and API combination. Mismatches are common when you have multiple applications or APIs.