Troubleshooting

Every request fails authentication

Check the following:

1. The API key was created in the production environment.
2. The request header is exactly X-API-Key and appears only once.
3. The key does not contain extra quotation marks, line breaks, or other characters.
4. The key has not been disabled, revoked, or expired.

Authentication failures do not disclose the exact reason. If you cannot determine the cause, create a new key in the web console and replace the configured value.

Error 300370 is returned

The request's source IPv4 address does not match the user-level Open API IP allowlist. Sign in to the production web console, check the caller's actual public egress IPv4 address, and add it to the IP access allowlist. All API keys belonging to the same user share this configuration.

Changes to the allowlist switch or address list may take up to 30 seconds to take effect. If the configuration was just updated, wait for propagation before retrying. Switching to another API key owned by the same user does not bypass the allowlist.

HTTP 200 but the business operation did not succeed

This is the normal response convention. Read the response body code; only code = 0 means success. Handle nonzero results according to Error codes.

A non-200, non-JSON, or empty response is returned

This usually indicates a transport failure, such as DNS, TLS, an interrupted connection, or unexpected content returned by a CDN, gateway, WAF, or network proxy. Do not record such a result as business success.

Save any available X-TRACE-ID. If no trace ID is available, save the request time, request path, and your own request record. Read operations may be queried again after the network recovers. A write-operation transport failure does not prove that the request had no effect. Creation operations with request_no must not be resubmitted blindly with either the original or a new request number. First follow Request numbers and duplicate submissions. For other write operations, query the current state first.

The result of a creation request is uncertain

After a timeout, disconnect, non-JSON response, or empty response, do not blindly resubmit with the original request_no or a new one. request_no only prevents duplicate acceptance; it is not a result-query key and does not replay the original result.

First check existing order lists, account lists, balance, or resource-status APIs. If the outcome still cannot be determined uniquely, contact support with request_no, the call time, production Base URL, and X-TRACE-ID if available. Never provide the API key. See Request numbers and duplicate submissions.

A static order remains in progress

Continue querying the corresponding order list every 10–30 seconds, filtering by the exact order_no. Do not query continuously at high frequency. If processing takes longer than expected, prepare the following information for support:

• Production Base URL.
• API path.
• order_no.
• Request time.
• Response-header X-TRACE-ID.
• Response-body code.

Do not provide the API key, proxy password, or complete connection credentials.

No callback was received

Failed callbacks are not retried. Confirm that the receiving URL is publicly accessible, its HTTPS certificate is valid, and it does not return a redirect. Query the corresponding order list proactively. A callback is only a notification; the query result is authoritative.

Parameters appear correct but 400009 is returned

Check the following:

• The request does not contain unlisted JSON fields or query parameters.
• The same query parameter does not appear more than once.
• JSON strings, integers, and booleans use the correct JSON types.
• Enumeration values use the correct letter case.
• Timestamps include Z or an explicit offset.
• Traffic values are sent as plain decimal strings.