Special considerations and limitations
- API request policy
- API limitations
- Order changes
- Phone number format
- Order for loading data
- Recommended method for loading data
API request policy
- The API response timeout is 60 seconds.
- A single batch request can contain up to one thousand objects. If you need to send more data, divide it into several requests.
- In rare cases (less than 1% of requests), the Track & Trace API returns a 504 Gateway Timeout error. If you receive this error, repeat the request up to three times with a one-second pause.
- The accuracy of order address geocoding is not checked. The address in text format (set with the address parameter) and the order coordinates (set with the lat and lon parameters) must match each other.
Geographic coordinates are used to set the route. If the geolocation is not very accurate, the app may bring the courier to the wrong location instead of the one specified in text in the app. A common error is an address is given up to a house number but the coordinates point to the middle of the street.
- Cascade deletion of entities is not supported. You don't have to delete unnecessary entities with dependencies on other entities, because they don't interfere with anything.
- When you move a canceled order to another day, assign it the
newstatus. Otherwise, the order gets added to the route on another day with the
- When changing an order, only update the changed attributes. Otherwise, the data received from the courier will be overwritten. For example, the courier already delivered the order, but the system re-assigned the
newstatus to the order when updating another field.
- After uploading orders, check them using the verification resource. This ensures that there are no errors. Otherwise, the courier might not receive part of the orders. This verification must be performed daily and offline before the first courier departs.
route_numbervalue must be unique while using the API.
integerfields should be sent without quotation marks, while
stringfields should be sent in quotation marks.
Stringfields must be UTF-8 encoded.
Phone number format
- Phone numbers must be given in the format supported by the mobile employee terminal. For example, some terminals don't support phone numbers that start with 7. The app can't be used to make calls to this phone number. We recommend phone numbers starting with +7 or 8.
Order for loading data
We recommend loading data in the following order:
A different order may cause errors when accessing objects that haven't been loaded yet.
Recommended method for loading data
To upload and update your data, use
batch requests that load data arrays: depots-batch, couriers-batch, routes-batch, orders-batch.
Each uploaded object is assigned:
- A unique number used in requests to the Track & Trace API. Written in fields with the
_idpostfix, such as
- Unique number that matches the number in the delivery company's database. Written in fields with the
_numberpostfix, such as
Batch loading also updates existing data.
Each call is an ACID transaction. If an error calling the batch resource occurs, it cancels all the changes made to the call.
To minimize losses, split the data into several packages. In this case, only the changes in the package with the error will be lost.