Delivery Tech - Developers

# Introduction

Through seamless POS Integration, vendors and POS providers reach a new level of intercommunication. Vendors can process orders through their POS System using Delivery Hero’s integration solution.

This documentation contains all information to start your POS Integration with Delivery Hero.

# Terminology

Here is a detailed explanation of key terms used throughout this documentation:

  • POS Clients: Chains or POS providers seeking to receive orders coming from Delivery Hero directly on their POS System.
  • Vendors: Physical location where the food is prepared.
  • POS System: Point-of-sale software on POS Clients side which compiles orders and transactions (online and offline) for a certain number of vendors.
  • Integration Middleware: Delivery Hero order transmission system, in charge of forwarding orders placed on Delivery Hero platforms to the Vendor POS System.
  • Plugin: Adapter to be created by the POS Clients if they want to do POS Integrations with Delivery Hero. This adaptor serves to allow communication between - Delivery Hero Integration Middleware and Vendor POS System.
  • Delivery Hero Vendor App: Delivery Hero application for vendors where orders placed on a Delivery Hero platform can be processed (accepted or rejected). This application is running on a device provided by Delivery Hero Platform.

# Integration Process

  1. Request Credentials
  2. Develop your Plugin
  3. Provide the Plugin URL to your local representative (should support HTTPS protocol using a valid SSL certificate)
  4. Test orders from a test vendor (local representative will share the test vendor details)
  5. Rollout

# Request Credentials

You must request credentials to connect with Integration Middleware and start receiving orders.

To request credentials, please provide a valid Public PGP Key (more information about the PGP encryption method can be found in this video).

After request approval, your local representative will share your Credentials. Credentials are encrypted with the PGP key shared in the request form.

Credentials are composed of:

  • Username
  • Password
  • Secret

Read more about authentication here

Request credentials by signing up below to request credentials.

# Order Integration Flows

Delivery Hero offers order integrations through two different flows:

# Indirect Flow

Vendor is equipped with a Delivery Hero Vendor App to manage (accept or reject) incoming orders on a tablet. The Integration Middleware order transmission forwards accepted orders to the POS System.

Here is an illustration of the Indirect Flow and components involved in the order process:

Example 1

Note: Orders reach the plugins only if accepted on the Delivery Hero Vendor App before. Orders rejected or not accepted on the Delivery Hero Vendor App, will never be forwarded to the Vendor POS System.

Example (simplified): An order has been placed for the vendor BONJOUR. The order dispatching flow from Delivery Hero to BONJOUR POS System is the following:

  1. Customer places an order at a restaurant belonging to vendor BONJOUR on a Delivery Hero platform (i.e Foodpanda).
  2. Foodpanda pushes that order to Delivery Hero BONJOUR App running on a device provided by Delivery Hero platform (i.e Foodpanda).
  3. An employee at the vendor location accepts the order on Delivery Hero BONJOUR App.
  4. Order is pushed to Integration Middleware which forwards the order details to the BONJOUR plugin.
  5. Plugin dispatches the order to the POS System of BONJOUR.

# Direct Flow

Vendor is not equipped with a Delivery Hero Vendor App and only uses its POS system to process orders coming from Delivery Hero.

As illustrated here, each POS Client communicates with Delivery Hero resources only through a plugin:

Example 2

Example (simplified): Order has been placed for the Vendor BONJOUR. The flow for order dispatching until it reaches BONJOUR's plugin is the following:

  1. Customer places an order at vendor belonging to BONJOUR on a Delivery Hero platform (i.e. Foodpanda).
  2. Foodpanda pushes that order to Integration Middleware.
  3. Integration Middleware forwards the order to the BONJOUR plugin.
  4. BONJOUR plugin dispatches the order on the BONJOUR POS System.
  5. An employee at the vendor location must accept or reject the order on the BONJOUR POS software.

Note: Direct Integrations are allowed on a case by case basis. Please reach out to local point of contact to enquire and agree about the possibility to use Direct Flow for your integration.

# Requirements

For a Direct Flow integration, plugin and POS System must have the required functionalities. These provide end customers with the same expected service level as a Delivery Hero Vendor App.

Required functionalities are:

  • Ability to
    • manually accept and reject order on POS System at vendor location.
    • handle order cancellations after order was accepted on POS System.
    • mark that vendor is closed/busy for X amount of time (optional).
    • indicate a delay of order delivery time (optional).
  • Send back delivery time to Delivery Hero, when order is accepted, in programmable or manual manner and include an unique order identifier on Vendor side.
  • Provide a reject reason, when order is rejected, according to the available reject reason (link to reject reason list).
  • Notify Delivery Hero via manual push or by algorithm, when order is ready to be picked up by driver.
  • POS Clients should inform Delivery Hero and send unreachable status for this specific vendor, if vendor is not reachable from POS System.
  • POS Clients should again inform Delivery Hero and send a reachable status to Delivery Hero, when vendor is back online.
  • Use Delivery Hero Vendor App as a fallback to allow vendors processing orders on device in case of issues during order transmission between Integration Middleware and plugin.

# Build the Plugin

  • You must build a plugin to be able to receive orders from Delivery Hero.
  • Your plugin will translate incoming orders to a language understandable by your POS system.
  • Technical specification of all endpoints and actions available on the plugin scope can be found here.

# Send Order Updates

  • The Integration Middleware is used by chains or POS providers to accept or reject orders.
  • Technical specification of all endpoints and actions available on the Integration Middleware scope can be found here

# Update Availability

  • Integration Middleware API allows Vendors to state if they are open or closed.
  • If closed, the vendor will be marked as offline on the Delivery Hero platform and customers won't be able to place orders.
  • Technical specification of the endpoint can be found here.

# Supported Platforms

Integration Middleware is currently supporting the platforms listed below. If you don't find the platform you are looking for, please reach out to your local representative.

# Asia/Pacific

  • Foodpanda (Bangladesh)
  • Foodpanda (Cambodia)
  • Foodpanda (Hong Kong)
  • Foodpanda (Japan)
  • Foodpanda (Laos)
  • Foodpanda Malaysia
  • Foodpanda (Myanmar)
  • Foodpanda (Pakistan)
  • Foodpanda (Philippines)
  • Foodpanda Singapore
  • Foodpanda (Taiwan)
  • Foodpanda (Thailand)

# Middle East/North Africa

  • Hungerstation (Saudi Arabia)
  • Otlob (Egypt)
  • Talabat (United Arab Emirates)
  • Talabat (Kuwait)
  • Talabat (Bahrain)
  • Talabat (Oman)
  • Talabat (Qatar)
  • Talabat (Jordan)

# Europe

  • Damejidlo (Czech Republic)
  • eFood (Greece)
  • Foodora (Sweden)
  • Foodora (Finland)
  • Foodora (Norway)
  • Foodpanda (Bulgaria)
  • Foodpanda (Romania)
  • Hungry (Denmark)
  • Mjam (Austria)
  • Netpincer (Hungary)
  • Pauza (Croatia)

# Latin America

  • PedidosYa (Argentina)
  • PedidosYa (Bolivia)
  • PedidosYa (Chile)
  • PedidosYa (Panama)
  • PedidosYa (Paraguay)
  • PedidosYa (Uruguay)
  • PedidosYa (Dominican Republic)
  • PedidosYa (Venezuela)
  • PedidosYa (Honduras)
  • PedidosYa (El Salvador)
  • PedidosYa (Nicaragua)
  • PedidosYa (Peru)
  • PedidosYa (Ecuador)
  • PedidosYa (Costa Rica)
  • PedidosYa (Guetamala)

# Post-production agreement

  • Plugin maintainer should inform Delivery Hero about their upcoming system maintenance by sending an email (log-vendor-pos@deliveryhero.com) at least 24 hours in advance. This is strongly advised for Indirect flow and compulsory for Direct flow.
  • Plugin maintainer should provide contact details which will be used by Delivery Hero to escalate technical issues with the plugin. This is crucial for monitoring and reliable order dispatching.
  • The integration might get disabled by Delivery Hero whenever there is a technical issue with the plugin and provided contact is not responding. The integration will be re-activated once the issue is fixed by plugin maintainer.
  • Some features of an integration or even the whole integration might get disabled whenever certain article of the implementation contract ain't fulfilled.
  • Few common examples of missing implementation points:
    • Working cancellation endpoint on plugin side (for more details click here).
    • Rejecting an order while not providing proper reject reason (click on order_rejected after following the link).
    • Accepting an order with wrongly formatted date time (click on order_accepted after following the link).
    • Providing secured plugin endpoint which cannot be validated by curl command (check this page).

# Get Order Details

  • Integration Middleware also provide an Order Report Service to allow Vendors to query order details for orders placed less than 24 hours ago.
  • This service is not meant to be used for order processing, but only to request additional information for specific orders. Currently, canceled and accepted orders are being supported on this report service.
  • More information and technical specification for this service can be found here.

# Update Menu

The manual process of requesting an Update of Catalog Data from a Vendor on the Delivery Platform is very time-consuming, requires a lot of human resources on both sides, and is error-prone. In the worst case, it could lead to a bad customer experience, when a customer tries to order something that is not available anymore. The problems amplify if the Catalog of Vendor frequently changes.

The Catalog Import Api tackles this and allows POS Vendors to push catalog changes automatically to the Platforms, in order to reduce human effort.

On the other hand, if there are less frequent changes the benefits are outweighed up by the implementation and maintenance overhead. Plugin Maintainers should weigh the benefits against the technical overhead.

The Catalog Import API is the Replacement of the legacy Menu Import Api. Pos Vendors that want to automate the process should start with Catalog Import API. New implementations for the legacy Menu Import API are not allowed.

Vendors that are already integrated with the legacy Menu Import API should migrate soon after the new Catalog Import API gets stable to take advantage of the new features and improvements. An announcement will be made from your local Contact regarding the migration timeline, and the old Menu Importer API deprecation.