To authenticate your requests, we provide each client a pair of access token and secret
key. The secret key is only used for HMAC SHA-1 signing and not transmitted over the
wire along with your requests.Each request must contain identity authentication
information to confirm the identity and authority of the sender
introduction
Step 1: get token and key
Follow these steps to quickly complete identity authentication
| Test environment | Production environmen | ||||
|---|---|---|---|---|---|
| 1 | Host | http://qa.etowertech.com | Host | http://cn.etowertech.com | |
| 2 | Token | test5AdbzO5OEeOpvgAVXUFE0A | Token | Please contact the integrator | |
| 3 | Key | 79db9e5OEeOpvgAVXUFWSD | Key | Please contact the integrator | |
Step 2: Every request need contain the HTTP header
| Request Headers | ||
|---|---|---|
| X-WallTeach-Date | Request sending time | Time format： RFC1123 Format format：EEE, DD MM YYYY HH:MM:SS ZZZ Sample：Thu, 04 Nov 2021 03:39:28 GMT Notice: Greenwich Mean Time (GMT) is Beijing Time (GMT+8) minus 8 hours. |
| Authorization | The standard HTTP header carries the authentication signature. | Format: WallTech < Token>: <Base64 Encoded HMAC SHA-1 Hash> Sample：WallTech test5AdbzO5OEeOpvgAVXUFE0A:LhpcUyKXCaGcn3tVPwY4nX44XTA= Explain: <Access Token>: API Token Through the key, such as key=79db9e5OEeOpvgAVXUFWSD, use the SecretKeySpec |
| Content-Type | application/json | / |
| Accept | application/json | / |
Step 3 Start your API docking
You can now begin to integrate the etower API into your test / formal environment. For complete information on all API operations, refer to the generic
API documentation. For technical assistance, please email etowercs@walltechsystem.cn
1.2 Version and Backward Compatibility
The API is versioned, and different major versions use different URLs. For minor version
enhancement, we may add new features/properties, but never remove or change any
existing features/properties. API clients are required to tolerant newly added properties in
response JSON.
- For example, a REST call returns JSON like{"orderId": "12345", "price": 69, "priceCurrency": "AUD"}
API clients are required to be insensitive to new JSON properties in the future. But the
existing 3 properties won’t be removed or redefined. Should the response have a new
property in the future minor version release, the client implementation need still be able
to work.
- For example Add trackingno field {"orderId": "12345", "price": 69, "priceCurrency": "AUD", "trackingNo": "123456"}
Backward compatibility is not assured between major versions
1.3 Error Handling
Implementation errors that can be found and prevented at development stage are
handled using HTTP status code.
The description of HTTP status code:
- HTTP 2xx indicates successful returns in terms of implementation logic;
- 4xx is client side error
Like authentication signature mismatch, malformed JSON requests, inconsistent data,
etc.
Returned HTTP status codes are in accordance with HTTP protocol specification. These
problems can be prevented during development stage.
- 5xx is Service internal error,；
when it happens, please contact us for assistance.
- On the other hand, some "errors" cannot be prevented effectively.
An example can be wrong postcode. System cannot eliminate possible wrong postcode
since we get the postcode from e-commerce customers.
We have a different strategy for those errors. When that happens, REST API returns
HTTP status of 2xx, and the response JSON may contains specific return code
Encryption example
You can directly refer to the following code samples or download the compressed package API Signature Demo.zip