# Development Documentation
- Introduction
- Integration Flow
- Call Flow
- Debugging Methods
- Rate Limits
# Introduction
The CJ API offers a rich set of capability interfaces that developers can use to achieve integration of enterprise services and enterprise WeChat with the help of interface capabilities which can be quickly previewed by directory navigation. The navigation is aggregated and grouped by functional blocks, such as address book, push, etc..
For the API development, the guideline is Development Documentation > Get Access Token > API 2.0.
All interfaces must use the HTTPS protocol, JSON data format and UTF8 encoding. The interface description format is as follows.
Request method:
POST (HTTPS)
Request address:
...
Request package body.
...
Parameter description.
...
Permission Description.
...
Return results.
...
Description of parameters.
...
- The request method. All requests shall meet the https protocol, distinguishing HttpGet and HttpPost requests.
- The request address. Case matters.
- The request package body and parameter description. You should indicates the request parameter example and description, which includes field meanings and value ranges. You should refer to this definition scope when designing data structures.
- The permission description. You should indicate the use range of the interface. By default, it can only view the data under the current account. No invocation scenario need your special attention.
- The return results and description of parameters. You should indicates the request parameter example and description.
Important: To determine if an API call was successful:
- Success: HTTP status 200 AND (code=200 OR code=0 OR no code field present)
- Failure: HTTP status ≠ 200 OR code field present with a value other than 200 and 0 Please refer to the global error code documentation for specific error meanings.
The message is for reference only and is subject to change, so it cannot be used to determine whether the call was successful.
# Integration Flow
Integrating with the CJ API takes the 6 steps below. Click a step in the chart to open its documentation. Grey dashed boxes are optional.
flowchart LR
S1["① Get API Key"] --> S2["② Get Access Token"] --> S3["③ Sandbox test"] --> S4["④ Sync products"] --> S5["⑤ Order & pay<br/>(by scenario)"] --> S6["⑥ Logistics & after-sales"]
classDef optional fill:#f5f5f5,stroke:#999,stroke-dasharray:4 3,color:#666
class S3 optional
click S1 "/en/api/start/apikey.html"
click S2 "/en/api/start/token.html"
click S3 "/en/api/start/sandbox.html"
click S4 "/en/api/start/Products-Synchronization-Processing.html"
click S5 "/en/api/start/Orders-Synchronization-Processing.html"
click S6 "/en/api/api2/api/logistic.html"
| Step | What to do | Key APIs / Docs |
|---|---|---|
| ① Get API Key | Install the API app and create an API Key on the API page | How to Get API Key |
| ② Get Access Token | Exchange the API Key for tokens, cache them on your server, refresh before expiry | getAccessToken / refreshAccessToken; see "Interface call flow" below and the Authentication API |
| ③ Sandbox test (optional) | Pass isSandbox=1 when creating orders: no real payment or fulfillment | Sandbox |
| ④ Sync products | Get product list, details and variants, query real-time inventory; optionally subscribe to product / stock Webhooks | Products Synchronization Processing, Webhook |
| ⑤ Order & pay | Calculate freight, create orders, pay with balance or on the MyCJ website; choose the order scenario that fits your business | Orders Synchronization Processing, Shopping API |
| ⑥ Logistics & after-sales | Get tracking information or receive order / logistics Webhooks; open a dispute if there is a problem | Logistic API, Dispute API |
All calls are subject to rate limits and points rules throughout the process; see Interface Call Restrictions and Points Resource Rules.
# Interface call flow
flowchart TD
A([Start]) --> B{"Valid Access Token in your server cache?"}
B -- No --> C["Get Access Token with your API Key<br/>POST /authentication/getAccessToken"]
C --> D["Cache accessToken / refreshToken / expiry dates on your server"]
D --> E
B -- Yes --> E["Call the business API<br/>request header CJ-Access-Token: accessToken"]
E --> F{"HTTP 200 and code is 200 or 0?"}
F -- Yes --> G([Handle the response data])
F -- "No, code = 1600001<br/>(token invalid or expired)" --> H["Refresh Access Token<br/>POST /authentication/refreshAccessToken"]
H --> I{"Refresh succeeded?"}
I -- Yes --> D
I -- "No, code = 1600003<br/>(refresh token invalid)" --> C
F -- "No, other code" --> J(["Handle the error by code<br/>see Global Error Codes"])
Find the access token. Reference: documentation note.
- Cache and refresh access_token.
- You need to cache the access_token for subsequent calls to the interface. When the access_token is invalid or expired, it needs to be retrieved.
- Calling a specific business interface.
The Access Token and Refresh Token are each valid for 180 days. For error codes, see Global Error Codes.
# Basic debugging methods
Tools, such as postman, can be used to troubleshoot problems. Reference: documentation note
# Limitations on the frequency of calls
To ensure our platform remains stable and fair for everyone, all APIs are rate-limited. Reference: Active call frequency limit