API Gateway:Troubleshoot errors in the error code table

Causes

The HTTP schema in the request is invalid.

Different APIs support different HTTP schemas. API providers can configure their APIs to allow only HTTP requests, only HTTPS requests, 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 StringToSign parameter used to calculate the server-side signature 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.

Obtain the local StringToSign and compare it with the StringToSign returned in the response. If you used the official demo, you can retrieve the StringToSign through the signature calculation tool class.

Line breaks are not allowed in HTTP response headers, so line breaks in StringToSign are removed in the response. Refer to the documentation and compare the strings accordingly.

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. Specify the same HTTP method in your request as the API definition. For example, if an API needs to be called in the POST method, do not specify GET in your request.

2. Specify the path in your request based on the actual path in use. If you own the API, remember to republish it after you modify it.

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 and authorize it to call the API in the API Gateway console. An application is required even if you own the API and are calling it only for testing.

2. If you purchased the API, check the application details page to view the APIs that the application can call. If the target API is not listed, obtain authorization for the application.

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 calling the correct API. Mismatches are common when multiple applications or APIs exist.