Overview
All APIs share the same calling conventions. Read this page first, then jump to the specific API docs.
Basic information
| Item | Value |
|---|---|
| Base URL | https://yunsapi.com/api/v3/ |
| Data format | JSON |
| Encoding | UTF-8 |
| Methods | Mostly POST; some APIs support GET |
| Authentication | App ID + App Key |
Calling methods
Two equivalent forms are supported:
| Form | Pattern |
|---|---|
| Path form (recommended) | POST /api/v3/{api_code} |
| Parameter form | POST /api/v3/index.php?code={api_code} |
Example with the SMS verification API:
# Path form
curl -X POST https://yunsapi.com/api/v3/dxyzm \
-H "X-APP-ID: YOUR_APP_ID" \
-H "X-APP-KEY: YOUR_APP_KEY" \
-H "Content-Type: application/json" \
-d '{"phone":"13800138000"}'
# Parameter form
curl -X POST "https://yunsapi.com/api/v3/index.php?code=dxyzm" \
-H "X-APP-ID: YOUR_APP_ID" \
-H "X-APP-KEY: YOUR_APP_KEY" \
-H "Content-Type: application/json" \
-d '{"phone":"13800138000"}'
Authentication
Every request must carry credentials. Any of the three placements works; the priority is Header > GET > POST:
| Parameter | Placement | Description |
|---|---|---|
app_id | Header X-APP-ID / GET / POST | Application ID |
app_key | Header X-APP-KEY / GET / POST | Application secret |
The server reads the Header first, then GET, then POST. Using the Header consistently is recommended.
Response format
All APIs return a unified structure:
{
"code": 0,
"msg": "success",
"data": {},
"request_id": "req_xxx"
}
| Field | Type | Description |
|---|---|---|
code | int | Business status code; 0 means success, others refer to the error table |
msg | string | Message |
data | object | Business payload; may be empty on failure |
request_id | string | Request tracing ID; include it when reporting issues |
Signature
The current version authenticates directly with App ID + App Key and requires no extra signature parameters. RSA2 signing will be introduced in a later version; a migration plan and advance notice will be provided before the upgrade, and legacy calls stay valid during the transition.
Common parameters
Besides business parameters, every request may carry:
| Parameter | Type | Required | Description |
|---|---|---|---|
app_id | string | Yes | Application ID |
app_key | string | Yes | Application secret |
Parameter types
| Type | Description | Example |
|---|---|---|
| string | Text value | Name, phone number |
| integer | Whole number | Count, status code |
| float | Decimal number | Amount, score |
| boolean | True/false | Switch fields like generated |
| array | List | Mismatched field list |
| object | Nested structure | User info |
Common error codes
| Code | Description |
|---|---|
| 0 | Success |
| 1000 | Invalid request parameters |
| 1001 | Missing authentication info |
| 1002 | Invalid App ID |
| 1003 | Wrong App Key |
| 1004 | Application disabled |
| 1005 | API not purchased or package exhausted |
| 1009 | API not found |
| 1010 | Deduction failed |
| 1011 | Internal server error |
See Error Codes for the full list.