Rules
API rules check list
Your integration must follow these rules.
Tradecloud will review your integration in the acceptance test environment before going live.
Pitfall: JSON syntax does not assign any significance to the ordering of name/value pairs.
Identifier examples are:
supplierAccountNumber
buyerAccountNumber
purchaseOrderNumber
destination.code
position
item.number
deliverySchedule.position
salesOrderNumber
salesOrderPosition
contact.email
contact.userName
Your identifiers
- must be unique
- must never change
- must never be reassigned
Your identifiers must not contain whitespace characters.
The account number should be set on forehand in the Tradecloud connection with your supplier or buyer. You can set the account code when inviting a new connection or at any time in the connection overview in the portal.
Rules for any Tradecloud API request:
Send the next message when the previous one has been responded with HTTP Status Code 200 OK or 202 Accepted.
Do not send more than 10 requests per second.
The Tradecloud environments do not have an availability SLO of 100%. If Tradecloud is temporarily unavailable, it is the API client's responsibility to queue the message and automatically retry with exponential backoff till Tradecloud is available again. An alternative is to warn the ERP user, who is trying to send the message to Tradecloud, so the user can manually retry later.
If Tradecloud responds with either:
- a HTTP Status Code 5xx Server Error or
- the requests does time out (currently 5 secs. at Tradecloud API side)
Then the client must automatically retry, using an exponential backoff strategy, or use a manual retry strategy. The Exponential Backoff Calculator is handy to verify the retry plan.
Only send an order or order response that either is new or has an actual change
Never resend all or all active orders, responses, dispatch advices or forecasts periodically.
Resending periodically will result in processing delays and excessive network, server and storage resource usage.
The order or response should only contain order lines that are new or changed.
Sending all lines may result in processing delays and unnecessary network, server and storage resource usage.
The TOTAL number of objects is limited to 100 objects per collection by default.
Examples are:
- 100 documents in total per order
- 100 documents in total per order line
- 100 delivery lines per delivery schedule
- 100 delivery lines per delivery history
Exceptions are:
- 500 lines in total per order
- 500 lines in total per shipment
- 500 lines in total per supplier forecast
As buyer your integration should not change the order destination or line item when updating an order.
If you wish to change the order destination, or a line item, either:
- Discuss this with your supplier through the chat function in the Portal. If your supplier agrees, update the order(line) accordingly through your integration.
- Cancel the order(line) and create a new order(line) with the alternative destination or item.
Your integration must support a line delivery schedule with multiple schedule lines when sending or receiving an order, response or event.
If your ERP does not support a delivery schedule in an order line, this will conflict with split lines that may be sent back by your supplier. You can either:
- Map the delivery schedule lines that come in on ERP order lines in your integration.
- Aggregate Tradecloud's delivery schedule lines that are sent by your supplier as they come in, but never send an update regarding the delivery schedule after the order was created.
- Reject any supplier proposal or reopen request with split delivery lines.
Your integration must support the other party may add or remove a delivery schedule line.
Last modified 4mo ago