Just Eat API

This webhook will be invoked whenever an attempted delivery query has been resolved. Mocked via Mockzilla.

Get all brand orders within the specified time frame, optionally filtered by status and location. Example of orders overview endpoint with filters: /brands//orders?status=failure&from=2021-06-07T12:04:38.1518005Z&to=2021-06-07T14:04:38.1518005Z&page=2

Get the brand order full details by order id or order reference.

A delivery pool is a named group of drivers which deliver food for a set of restaurants.

A delivery pool is a named group of drivers which deliver food for a set of restaurants.

Get the current amount of time it will take a driver to collect a new order from a restaurant in the pool. Available as a Mockzilla mock endpoint.

Set the average amount of time it will take a driver to collect a new order from a restaurant in the pool.

Define the delivery pool risk level, in order for Demand Shaping to generate dynamic delivery area polygons for all restaurants in the delivery pool

The restaurants will no longer be associated with the pool.

A delivery pool is a named group of drivers which deliver food for a set of restaurants.

Modify a delivery pool, changing its name, restaurants or both. Mockzilla mock: no signup, no API key.

Replace an existing delivery pool changing all of its properties

Set the daily start and end times for a pool or set closed flag if the pool does not operate on that day. Start and end times for all days must be provided. Though the API accepts array of start and end times for each day, multiple start and end time for a day are not accepted. If the end time for a day is equal to or before start time, end time will be considered as time for the next day.

Delete offline events for a delivery pool

Take delivery pool offline

Remove restaurants from a delivery pool. Served by the Mockzilla mock runtime.

Add additional restaurants to a delivery pool

Get delivery pool's status and list of events

This webhook will be invoked whenever an attempted delivery event is created from the device.

Retrieve delivery fees for many restaurants. Returns fees and minimum order values required for delivery orders.

Get a ranked collection of restaurants that serve the provided postcode area along with additional information. Mocked via Mockzilla.

Get a ranked collection of restaurants that serve the provided latitude and longitude along with additional information.

Driver Assigned to Delivery

Driver at delivery address

Driver at restaurant

Driver has delivered order. Available as a Mockzilla mock endpoint.

Driver Location

Driver on their way to delivery address

Final picked order is for brands that may make amendments to an order and want to receive a copy of the order in its final state i.e. after all amendments have applied. This can be integrated or non integrated. please contact your brand manager for more information. after the initial order injection has already taken place (e.g. due to items potentially being out of stock), and would like to be notified of these changes to the initial order. Once the order has been picked (currently the trigger point for this is the "last mile delivered" event), the platform will check for any amendments on the order, and send the "final picked" order back to the specified endpoint. The "final picked" order could be different from the original order, as items may have been marked out of stock during the order pick. As such the total price, or item quantities may have changed. In the event you would like to receive the final order, there are several combinations of injections you can subscribe to. Scenario 1 (receive only the initial order) Receive only the initial order in the state it was originally placed, at the point the driver is prep time away from the store. JET Connect will send the order to the "Received Order" endpoint, as a POST request. Your endpoint must be able to receive orders in the same format documented in the "Received Order" section. Scenario 2 (receive only the final pick order) When the order is picked, the JET Connect Platform will check for amendments, and send a request to the final picked order endpoint you provided with any changes, as a POST request. Your endpoint must be able to receive orders in the format documented under "request format". Scenario 3 (receive both the initial order, and the final pick order) If you would like to receive both of the requests documented above, this is also possible. Please contact your brand manager to have this configured. Request format As an additional security measure, orders can be sent from the same static IP address as the initial order. You can request this feature from your brand manager.

When an order is received for your integrated restaurant on a delivery website, the JET Connect Platform will send it to the endpoint you provided, as a POST request. Your endpoint must be able to receive orders in the format documented below. As an additional security measure, orders can be sent from a static IP address. You can request this feature from your brand manager.

The Item Availability API allows you to manage which items on a menu are available for ordering via your delivery partner (Just Eat, Skip The Dishes, Menulog or Takeaway). Menu items are marked as available or unavailable via requests to the Update Item Availability endpoint described below. Features - Static endpoints for updating Item Availability. These endpoints do not include brand and location references in the endpoint URL, making it easier for operations teams to onboard new restaurants. - The ability to update multiple menu item availabilities in a single request. - Coming soon: more detailed error messages, including whether the operation failed when attempting to publish your update to the delivery partner (Just Eat, Skip The Dishes or Menulog). Response If the menu and PLU references are valid and the request was accepted, you will receive a 202 Accepted response. The specified menu item should appear as available or unavailable on the delivery partner website (e.g. Just Eat, Skip The Dishes, Takeaway) automatically within less than 5 minutes. Mockzilla mock: no signup, no API key.

This webhook will be invoked when a late order compensation query has been raised and a restaurant response is required.

This webhook will be invoked when a late order query has been raised and a restaurant response is required.

Get all orders from the location within the specified time frame, optionally filtered by status.

Callback to confirm that an attempt to ingest a menu has completed either successfully or unsuccessfully

Use this endpoint to ingest menu(s), creating a baseline per menu received. How it works The JET Connect Platform API allows anyone with a Just Eat, Skip The Dishes, Menulog or Takeaway account to automatically publish menus from their POS to the respective delivery partner. For this to work, client applications need to: 1. Extract menu data from their POS 2. Use this data to create an HTTP request in JSON format (see format details below) 3. Send the request to the menu API endpoint: https://api.flytplatform.com/menus The API endpoint will validate the incoming request and, if checks are successful, publish the new menu to the delivery partner. We recommend checking the delivery partner page to see if the new menu has been updated as intended. Features - Static endpoints for publishing menus. These endpoints do not include brand and location references in the endpoint URL, making it easier for operations teams to onboard new restaurants. - Ability to update menus for multiple restaurants using a single request. Response Format If the menus are valid and the request was accepted, you will receive a 202 Accepted response. The new menu should appear on the delivery partner website (e.g. Just Eat, Skip The Dishes, Takeaway) website automatically within less than 5 minutes. Note: currently, our platform only checks if the menu structure is valid. However, a valid menu may still fail to publish on the corresponding delivery partner platform. Currently, this endpoint does not indicate whether the publish operation was successful, however this is an item on our future roadmap Asynchronous Callbacks If a valid callback address has been specified, shortly after the synchronous response indicating initial acceptance or rejection of the menu, a POST request will be made to the address detailing the eventual menu state. See the callback object for more details. Nutrition and Servings in menus - Under Development This version has initial support to provide nutritional information and servings in your menu data. This is still under active development and it's currently not supported by any of the delivery partners. Nutritional info and servings in menus will be available in the UK only from 6th April 2022. Restaurants in the UK territory are able to integrate now with our platform API with full testing and rollout to happen from mid - end February 2022 onwards. Please note that it is mandatory in the UK to have nutritional information for brands/restaurant groups with over 250 employees (UK government guidance link). Here are the additional attributes covering nutritional_info and servings under items, options, or portions. See sample payload "Menu with nutrition and servings". Grocery items in menus - Under Development This version now has initial support for you to provide grocery items in your menu data. This is still under active development and it's currently not supported by any of the delivery partners. Here are the additional attributes to add under items, options, or portions: See sample payload "Menu with grocery items". Translations - Under Development We will be beginning support for menu translations shortly, to any platform which supports it. This section will contain further information on supported platforms in the future. Served by the Mockzilla mock runtime.

Marks the order status of a pending order as failed to inject. This does not mean that the order is rejected, as the order will go through the backup flow, if any. Orders are marked pending when you respond to a call to the Receive Order endpoint with a 202 status. Requests to this endpoint for an order which is no longer pending will fail. If this endpoint is not called within 3 minutes after an order is marked as pending, the order status will switch to "failed to inject". If you are receiving multiple transmissions for the same order, e.g. Initial and Final Picked Order, then you need to provide the Transmission ID from the order payload in the request body.

Marks the order status of a pending order as successful. Orders are marked pending when you respond from a call to the Receive Order endpoint with a 202 status. Requests to this endpoint for an order which is no longer pending will fail. If this endpoint is not called within 3 minutes after an order is marked as pending, the order status will switch to "failed to inject". If you are receiving multiple transmissions for the same order, e.g. Initial and Final Picked Order, then you need to provide the Transmission ID from the order payload in the request body.

This webhook will be invoked whenever the order was accepted.

This webhook will be invoked whenever the order was cancelled.

This webhook will be invoked for every cancelled order and it will inform if the order is eligible for compensation. Mocked via Mockzilla.

The "Ready for pickup" event lets the delivery partner know that the food has been cooked and is now ready for collection up from the restaurant.When this event is received, it is important that you let your driver know that the order should now be collected from inside the restaurant. For example, this driver notification could take the form of an in-app notification or an SMS message.This communication is needed to support restaurants who are unable to accommodate drivers inside their premises, as it allows restaurants to notify drivers waiting outside that they should come inside to collect their order.NB; This event can be sent by the restaurant at any point after the order is accepted by the restaurant (for instance, this event may be sent before the driver has arrived at the restaurant).

This webhook will be invoked when we have determined that an order is ready for preparation. Upon receiving the request, you should perform any preparation-related activities, such as sending the order to the POS system / kitchen screen. NOTE: This version of the webhook is asynchronous, and we expect a response in two parts: 1. We expect an immediate 202 response from this webhook to denote that you have received the request; 2. Following that, we expect an async callback - indicating either success or failure of the operation. The body for the async callbacks are as below: Success callback { "status": "Success", "message": "Order successfully sent to POS", "data": {} } Failure callback { "status": "Failure", "message": "{errorMessage}", // e.g. "The POS is currently in use" "data": {} }

This webhook will be invoked when we have determined that an order is ready for preparation. Upon receiving the request, you should perform any preparation-related activities, such as sending the order to the POS system / kitchen screen.

This webhook will be invoked whenever the order was rejected.

This webhook will be invoked when we have determined that an order is required acceptance for delivery. Upon receiving the request, the order should be scheduled for pickup by a courier/driver. We expect an immediate 201 response from this webhook to denote that you have received the request. Available as a Mockzilla mock endpoint.

Callback to notify recipients that there has been a change to the restaurant order times for a given day and service type

This webhook will be invoked whenever new order for restaurant has been created.

Current driver location (bulk upload)

Get progress about the state of an amended order.

Amends an order to mark items that were out of stock. Upon completion of this amendment process, any failures will reported via the orderAmendmentFailurePath webhook. This can be configured inside your brand config defined in connect.flyt.io. Contact your delivery manager if you are unsure how to set this. Mockzilla mock: no signup, no API key.

The at delivery address callback should be sent when the driver thinks that they have arrived at the specified delivery address.NB; This callback should be distinct from the delivered callback, as Just Eat use this callback to understand how much time is spent locating the customer's address.

The at restaurant callback should be sent when the driver arrives at the restaurant and is ready to collect the order.

In the UK, this endpoint updates the estimated arrival time at the restaurant. This value can be overridden from other endpoints like Driver Locations This endpoint should be used to set initial at restaurant ETAs prior to driver assignment where available. The earlier a delivery partner is able to provide an estimate of when the driver will arrive at the restaurant the more likely it is that driver arrival and order preparation will be aligned. In other tenants (Not UK):Note that if set for a given order, this Eta will NOT be overridden by any other at restaurant ETAs provided in DriverAssigned or DriverLocation requests This value is significant since it informs when a restaurant is instructed to start preparing food. When the time remaining between current time and the estimated time of arrival becomes less than the restaurant's configured preparation time, food preparation is initiated

The delivered callback should be sent when the driver has handed the food to the customer and completed the order.

The driver assigned callback should be sent when a driver is assigned to the order. It should communicate important details about the driver - and also an estimated time for the driver to arrive at the restaurant and delivery address. Served by the Mockzilla mock runtime.

Just Eat requires all delivery partners to send regular driver location callbacks, that record the GPS location of the drivers assigned to each orderPartners should aim to supply this callback approximately every 10 seconds.Please provide an up-to-date ETA for when the driver will reach the restaurant in this request - this value is significant since it informs when a restaurant is instructed to start preparing food - when the time remaining between current time and the estimated time of arrival becomes less than the restaurant's configured preparation time, food preparation is initiatedNote that at restaurant Eta provided in this request will NOT override any ETA set in the Driver At Restaurant Eta request

The driver unassigned callback should be sent when a driver is unassigned from the order. It may details about the reason for cancelling the assignment, the driver details, and any newer at restaurant and customer estimations.

The on its way callback should be sent when the driver departs the restaurant with the customer's order. It should contain an ETA that records when the driver expects to arrive at the customer's address.

This webhook will be invoked whenever the customer responds to the attempted delivery notification.

Callback to notify that a restaurant has been taken offline through an active Restaurant Event or there's been a change in whether the restaurant can override a previous offline status. Mocked via Mockzilla.

Callback to notify that a restaurant is now able to come back online as there are no longer any active offline Restaurant Events

Provides details of all restaurants that deliver to the specified location

Provides details of restaurants that deliver to the specified postcode

Set the average amount of time it will take a driver to collect a new order from a restaurant.

Marks a restaurant as offline, i.e. unable to accept new orders. Note: This feature is currently only available for integrations with Just Eat and Menulog. Available as a Mockzilla mock endpoint.

Marks a restaurant as online, i.e. able to accept new orders. Note: This feature is currently only available for integrations with Just Eat and Menulog.

Update the service times in your Just Eat / Menulog restaurants, overriding the ones currently present on the restaurant. Note: This feature is currently only available for integrations with Just Eat and Menulog. When to use it By availabilities on the menu, we mean what times you can order from a specific menu. By service times, we mean restaurant opening hours. It is possible to push the same menu to multiple locations however, this means that all the restaurants need to share the same availabilities on the menu. By using this endpoint you can “override” the service times for a given restaurant, so you will be able to push a single menu and then individually select the service times. Scenario 1 You push 1 unique menu with availabilities 17:00-21:00 to ten locations. Since one of the locations closes earlier at 20:00 you can now use the service times endpoint to update the opening hours for this location. Scenario 2 The breakfast menu runs from 09:00-11:00 but the restaurant needs to close at 10:00 due to driver shortage. You can use the service times endpoint to update opening hours. Scenario 3 - Limitations Menu availabilities are 8:00-12:00. The restaurant decides on the day they want to open earlier at 07:00. The service times endpoint cannot be used to update opening hours as you won't be able to place an order at 07:00 since there is no menu for that time. Instead, you would need to re-push the menu with revised availabilities 07:00-12:00.

This webhook will be invoked if we experience an error or timeout in sending an order to the underlying POS / kitchen screen. When notified via this webhook, typically you will perform some form of alerting or backup flow (e.g. ask the operator to enter the order manually into the POS). NOTE: This message contains the OrderId, but not the full order. It is assumed that you have stored/cached the full order details earlier in the flow - e.g. via the /order-ready-for-preparation webhook.

When an order for your integrated restaurant has been cancelled, the JET Connect Platform will notify the endpoint you provided via a POST request. Your endpoint must be able to receive requests in the format documented below.

JET Connect Platform will notify the endpoint you provided via a POST request with updates related to the driver status. Your endpoint must be able to receive requests in the format documented below. Mockzilla mock: no signup, no API key.

JET Connect Platform will notify the endpoint you provided via a POST request with information related to an order that failed validation on our end so that you can initiate a (manual) backup flow. Your endpoint must be able to receive requests in the format documented below.

JET Connect Platform will notify the endpoint you provided via a POST request with updates related to restaurant service type being set offline temporarily or back online. Your endpoint must be able to receive requests in the format documented below.