1. Trans.eu Api
  2. Use cases
  3. Description of data flow between API methods

Description of data flow between API methods


1. Streamlining and Visualizing the Flow of Inter-Method Dependencies

To max­i­mize inte­gra­tion with the Trans.eu API and stream­line the process of build­ing your solu­tions, we present detailed descrip­tions and visu­al­iza­tions of key data flows and depen­den­cies between indi­vid­ual API meth­ods. Under­stand­ing how object iden­ti­fiers (IDs) and sta­tus­es flow through the sys­tem is essen­tial for effec­tive freight and trans­port order man­age­ment.

The pur­pose of this sec­tion:
•Visu­al­ize the full life­cy­cle of key objects (e.g., freight, trans­port orders).
•Explain which iden­ti­fiers (IDs) are gen­er­at­ed by each method and which are required as input for sub­se­quent oper­a­tions.
•Present the log­i­cal con­nec­tions between var­i­ous API mod­ules (e.g., Freight, Trans­port Orders, Dock Sched­uler, Mon­i­tor­ing).

1.1. Process Flow Dia­grams

We rec­om­mend using the fol­low­ing dia­grams, which illus­trate the flow of data in key busi­ness sce­nar­ios. Each dia­gram focus­es on a spe­cif­ic process, show­ing the sequence of API calls and the rela­tion­ships between objects.
•Freight Life­cy­cle Dia­gram: Shows the path from freight post­ing to its ful­fill­ment or archiv­ing.
•Trans­porta­tion Order Life­cy­cle Dia­gram: Illus­trates the process of cre­at­ing and man­ag­ing a trans­port order, includ­ing con­nec­tions to freight and mon­i­tor­ing tasks.
•Noti­fi­ca­tion Life­cy­cle Dia­gram (Dock Sched­uler): Shows the process of cre­at­ing and man­ag­ing noti­fi­ca­tions at the docks.

1.2. ID Depen­den­cies Matrix

The table below shows key API meth­ods, the iden­ti­fiers they return, and the meth­ods that require these iden­ti­fiers to func­tion cor­rect­ly. This allows you to quick­ly under­stand the data flow.

API mod­uleMethod/EndpointReturned ID (Exam­ple)Meth­ods requir­ing this IDCom­ments
FreightsPOST /ex­t/freights-api/v1/freight-exchangefreight-id: 8906773- GET /ext/freights-api/v1/freights/{freight-id}
- GET /ext/freights-api/v1/freights/{freightId}/offers
- POST /ext/freights-api/v1/freights/{freight-id}/archive
- POST /ext/freights-api/v1/cancelPublication/{freight-id} — PUT /ext/freights-api/v1/freights/:freightId/refresh_publication
- POST /ext/freights-api/v1/freights/{FeightID}/internal-note
freight-id is gen­er­at­ed after suc­cess­ful freight post­ing, regard­less of the post­ing method (e.g. freight-employ­ees, freight-com­pa­nies, freight-auto, pri­vate-exchange, freight-cor­po­rate).
FreightsGET /ext/freights-api/v1/freights/{freightId}/offersoffer-id: 4a2dbtsd-bd6b-4c24-6t2c-256af10055911617- POST /ext/freights-api/v1/freights/offers/{offer-id}/accept
- GET /ext/freights-api/v1/freights/offers/{offers-id}
- PATCH /ext/freights-api/v1/freights/offers/{offer-id}/negotiate
- POST /ext/freights-api/v1/freights/offers/{offer-id}/reject		offer-id is a unique offer iden­ti­fi­er returned by the API after receiv­ing offers from car­ri­ers.
Trans­port ordersPOST /ex­t/orders-api/v1/orders-cre­at­ed
POST /ex­t/orders-api/v1/order­s/await­ing-entry-exe­cu­tion-data		order-id: da012de9-faca-4b14-b380-9b94aadf­f6­fa24…- GET /ext/orders-api/v1/orders-created/{order-id} — POST /ext/orders-api/v1/orders-created/{order-Id}/arrived
- POST /ext/orders-api/v1/orders-created/{orderId}/unloaded
- PATCH /ext/orders-api/v1/orders-created/{order-Id}/confirm
- POST /ext/orders-api/v1/orders/{OrderID}/required-execution-data/provide
- POST /ext/orders-api/v1/orders-created/{order-id}/archive
- PATCH /ext/orders-api/v1/orders/{orderId}
- POST /orders-api/v1/orders/{orderId}/attachments
order-id is gen­er­at­ed after cre­at­ing a new trans­port order or after accept­ing freight (e.g. with the send_order_proposal_automatically option). It is in UUID for­mat.
Trans­ports in real­iza­tionGET /ex­t/­trans­ports-api/v1/­trans­portstransport_task_id: e6b7494b-4922–4fdb-af28-97618b8fb85739- GET /ext/transports-api/v1/transports/{transport_task_id}- GET /ext/transports-api/v1/transports/{transport_task_id}/monitoring
Trans­ports in progress are part of an accept­ed trans­port order.
Dock Sched­ulerPOST /ex­t/­dock-sched­uler-api/v1/an­nounce­mentannounce­ment-id: 3860244- PUT /ext/dock-scheduler-api/v1/announcement/{{announcementID}}/stage
- PATCH /ext/dock-scheduler-api/v1/announcement/{annoucementID}/slot
- DELETE /ext/dock-scheduler-api/v1/announcement/{announcementID}
- GET /ext/dock-scheduler-api/v1/announcement/{announcementID}
- GET /ext/dock-scheduler-api/v1/announcement/{announcement-id}/history
- PUT /ext/dock-scheduler-api/v1/announcement/{annoucementID}		announce­ment-id is the announce­ment iden­ti­fi­er in the Dock Sched­uler.
Vehi­cle ExchangePOST /ex­t/ve­hi­cles-api/v1/ve­hi­clesofferId: 01E4WTST4JK6HT6SZD8PDY7BDS- DELETE /ext/vehicles-api/v1/vehicles/:offerId
- GET /ext/vehicles-api/v1/vehicles/{id} — PUT /ext/vehicles-api/v1/vehicles/:offerId		The offerId for a vehi­cle offer is gen­er­at­ed after it is cre­at­ed.

1.3. How to use ID depen­den­cies:

1. Cre­at­ing an object: After suc­cess­ful­ly call­ing a method that cre­ates a new object (e.g. freight, trans­port order, noti­fi­ca­tion), the sys­tem will return the unique iden­ti­fi­er (ID) of this object in the JSON response

2.Fetching and updat­ing: This returned ID is then used in the URLs (end­points) of sub­se­quent meth­ods (e.g. GET, PUT, PATCH, DELETE) to ref­er­ence the spe­cif­ic object, retrieve its details, update its sta­tus, or mod­i­fy its prop­er­ties

3.Status Mon­i­tor­ing: Many meth­ods sup­port callback_url, which allows you to asyn­chro­nous­ly receive noti­fi­ca­tions of object sta­tus changes, elim­i­nat­ing the need for con­stant API polling.To use this fea­ture, you must pro­vide the callback_url field in the object cre­ation request.