FlashTrak API Test
Number of APIs: 13
Introduction The purpose of this document is to set the design requirements of the Application Programming Interface (API) for supporting the data integration services of the FlashTrak-RTL Web Application. The FlashTrak-RTL Wed Application is used for managing transportation conditions with the Real Time Data Loggers (RTL) of DeltaTrak. General Requirements The following general requirements shall apply to the FlashTrak Data Service:
The FlashTrak-RTL data service shall be available at data.flashtrakrtl.com via a secure connection.
The service shall respond when entering its URL in a web browser. The response shall be in the format of text such as “FlashTrak-RTL API x.x”, where x.x shall represent the current version of the API software. Any additional interaction with the service shall require Client’s Authentication.
The FlashTrak-RTL Service shall require Token string for authenticating Client’s requests. The Client must have an existing User profile in the FlashTrak-RTL Application and must be a member of the Account Administrators group i.e. a User with all access rights. The Client authentication shall be required for every transaction using the API.
A token for accessing the FlashTrak-RTL Service can be generated upon request by contacting DeltaTrak customer support.
Transactions with the services shall use JSON data objects. Every API function shall have its own JSON service end point.
1. Customer Endpoints-Locations - List Airport*
GET {{baseUrl}}/location?type=airport
List all locations and shared locations
■ Pulls back locations (of all types) belonging to account, plus shipments shared
with account (explicit & receiver sharing)
■ Ability to filter locations would be nice, but not required - this is typically a
smaller dataset
■ Each location node should contain the account ID that it belongs to
2. Customer Endpoints-Products - Query Count - check
GET {{baseUrl}}/product?query=count
List all products and shared products
■ Pulls back products belonging to account, plus products shared with account
(explicit & receiver sharing)
■ Each location node should contain the account ID that it belongs to
■ Since alarm criteria are defined at the product level, include array of alarm
criteria definitions associated with each product
3. Customer Endpoints-Shipments-List by Status - Status Completed
GET {{baseUrl}}/shipment?status=Completed
Find Shipments that match specified criteria
■ Should pull back shipments belonging to account, plus shipments shared with
account (explicit & receiver sharing)
■ Optional filters reduce results, and no parameters return all shipments for
account (see above)
■ Should include locations, product, alarm criteria(s), and list of shipment alerts
4. Customer Endpoints-Shipments-Query - Query Count Last Updated
GET {{baseUrl}}/shipment?query=last_input
Find Shipments that match specified criteria
■ Should pull back shipments belonging to account, plus shipments shared with
account (explicit & receiver sharing)
■ Optional filters reduce results, and no parameters return all shipments for
account (see above)
■ Should include locations, product, alarm criteria(s), and list of shipment alerts
5. Customer Endpoints-Shipments - Trip Number
GET {{baseUrl}}/shipment?tripNumber=TAGO1225
Find Shipments that match specified criteria
■ Should pull back shipments belonging to account, plus shipments shared with
account (explicit & receiver sharing)
■ Optional filters reduce results, and no parameters return all shipments for
account (see above)
■ Should include locations, product, alarm criteria(s), and list of shipment alerts
6. Customer Endpoints-Shipments - Get End Date
GET {{baseUrl}}/shipment/:tripNumber/readings?end_date=2023-01-24 21:00
Gets the sensor data recorded for the requested Shipment ID
■ Returns device reading array for single shipment
■ Includes separate array of maritime/sea-rates vessel geo-locations, if exists
7. Customer Endpoints-Shipments - Create
POST {{baseUrl}}/shipment
Creates new empty shipment record for a specific RTL Device ID. The Device ID must be free and not used for any other shipment with Incomplete status.
■ Ability to specify a single Product ID
■ Ability to specify locations (Shipper Location ID, Receiver Location ID, Airport
and Marine Port IDs, etc)
■ Available receiver locations include this account's receiver locations, plus any
receiver locations shared by receiver sharing
■ If user specifies a 3rd party receiver location, then the list of available products
to associate is limited to that receiver's locations, meaning product and receiver
location must match accounts
■ API should throw an error if the selected product doesn't match the account of
the selected receiver location.
8. Customer Endpoints-Shipments - Edit [In-Progress]
PUT {{baseUrl}}/shipment/:tripNumber
Edit a Shipment with Incomplete status. Completed shipments shall no longer receive data from the associated Device ID.
■ Same criteria/rules as above
■ Will missing optional parameters clear that existing field in the DB, or leave that
field untouched? Think clearing is better, meaning the entire dataset is required.
9. Customer Endpoints-Shipments - Complete Shipment
PUT {{baseUrl}}/shipment/:tripNumber/complete
Edit a Shipment with Incomplete status. Completed shipments shall no longer receive data from the associated Device ID.
■ Empty body?
■ Completes the shipment, if belonging to account
■ Don't believe we need to take sharing into consideration
10. Customer Endpoints-Shipments - Delete
DELETE {{baseUrl}}/shipment/:tripNumber
Deletes a Shipment with Complete status. Deleting the Shipment shall also remove all
of its sensors’ data records.
■ Deletes the shipment (by marking in DB as deleted), if belonging to account
■ Don't believe we need to take sharing into consideration
11. Accounts Copy - Invalid Token
POST {{baseUrl}}/account
12. Accounts Copy - Invalid Token
GET {{baseUrl}}/account
13. Accounts Copy - Invalid Account ID
DELETE {{baseUrl}}/account/:accountID