Open APIs

Hi,

Question: Is there any standard TMForum API specification available in TMForum which can provide the "Estimated/Expected Delivery Time" before customer places an order on the channel? Putting down my thoughts around the question:

• In the Open API table the closest API which refers to expectedDeliveryDate is TMF700 i.e. 'ShippingOrder API'. Here delivery date is an attribute of ShippingOrder, which considers that the expectedDeliveryDate is already known. 
• To know the expectedDeliveryDate, another Open API available in TMForum TMF646 which returns the appointments. Can this be used for expectedDeliveryDate? If yes, then:
  • What does CalendarEntry signifies here as it is not returning the date/time.
  • When using 3rd Party Logistics, ContactMedium will not be available, is it ok to ignore that attribute (non-mandatory).

Pls suggest.

In TMF646 v4, there is an operation /searchTimeSlots. This operation provides TimeSlots which are related to either work order (customer visit) or contacting customers in a given time slot. 

Considering our use case would involve product delivery by 3rd party logistics partner. The delivery of product to the customer resonates with work order (customer visit) however not fully. Here telco would have the responsibility of showing the expected delivery date to the customer based on the agreed SLA/contracts with 3rd party logistics. 

• With this context, can this operation still be leveraged?
• If yes, any additional aspects that must be to be taken around that use case?

Ramit - your read is right on both counts: TMF700 carries expectedDeliveryDate as an attribute it stores, not one it derives, and TMF646 /searchTimeSlots is an appointment-slotting primitive (a visit/install window), not a pre-order delivery oracle. That's why it won't sit cleanly on a 3PL parcel case.

What helped me stop fighting the spec: the "estimated delivery date" shown before the order is placed is a promise, not a stored resource. It's a computed capability - an available-to-promise / SLA calc reading carrier lead time, cutoff, stock position and destination - so no single Open API owns it, and hunting for the one that does keeps you in circles. You compose it: expose the estimate pre-order as a characteristic on the quote/basket, and only persist expectedDeliveryDate on the ShippingOrder once TMF700 actually exists.

Reach for TMF646 only where delivery maps to a bookable slot - home install, engineer visit, self-collect. For pure 3PL parcel there's no slot to book; you're showing an SLA-derived window, and CalendarEntry gives you a window definition, not a date - exactly the mismatch you flagged. Binding to a date happens when you book, not when you estimate.

Where this bites in delivery is drift. The promise computed at 2pm and the date the ShippingOrder lands on diverge the moment an order is placed after the carrier cutoff at 2am - same product, next-day slip. Then the 3PL webhook returns its own committed date, which can contradict what the customer already saw. So the operational questions: after capture, which date is the customer-facing source of truth - your promise or the carrier's commit - and does the journey re-notify on divergence? And on a multi-item basket, one journey date or per-item? A single 'expected delivery' on a mixed order is what generates the 'where's my other box' call.

ContactMedium - yes, safe to omit for 3PL (non-mandatory), but stash the carrier tracking/reference as a characteristic or you lose the reconciliation hook later.

How are you treating the shown estimate in your channel - contractual, or advisory? That usually decides the reconciliation rule more than which spec holds the field.