Request numbers and duplicate submissions

The following four APIs require request_no:

• Purchase dynamic traffic.
• Create a dynamic sub-account.
• Create a static proxy purchase order.
• Create a static proxy renewal order.

Format

request_no must contain 1–64 characters and may include only:

• Uppercase and lowercase English letters: A-Z and a-z.
• Digits: 0-9.
• Underscores: _.
• Hyphens: -.

Request numbers are case-sensitive. We recommend combining a business type, date, and caller-generated unique sequence, for example static-buy-20260824-001.

Scope of use

request_no only prevents the same operation from being accepted more than once. It is not a result-query key and cannot directly retrieve the result of the first request. A duplicate submission does not replay the first response and is not guaranteed to produce the same business result.

Receiving 300006 only means that the request number has already been used during its protection period. It does not indicate whether the first request succeeded or failed.

Protection scope

The same account, operation, and request_no may be submitted only once within 24 hours. A duplicate returns 300006. Different API keys under the same account share this protection scope; changing the API key does not bypass duplicate-submission protection.

This mechanism rejects duplicate acceptance and does not return the result of the first request. Once the first request enters processing, the request number remains reserved for 24 hours regardless of success, failure, or a caller-side network timeout. Retrying does not release or extend the reservation.

After the protection period expires, reusing the same request_no is treated as a new operation and may create a new business result. Generate a request number that has never been used for every new business operation.

Handling uncertain results

If a write request times out, disconnects, or returns a non-JSON or empty response:

1. Do not blindly resubmit with either the original request_no or a new one.
2. First use existing list, detail, balance, batch, or resource-status APIs to determine the result.
3. request_no is not itself a query filter. Match the operation using the request content, request time, and known business facts stored by your application.
4. Not finding a result immediately does not prove that the first request had no effect. Continue checking in relation to the original request time.
5. If the result still cannot be determined uniquely, contact support and provide request_no, the request time, environment, and X-TRACE-ID if available. Never provide the API key.

Store request_no, request content, request time, environment, X-TRACE-ID, and any known order number together to support recovery and troubleshooting.