Guides
Start typing to search…

Points to Consider

Is your menu food aggregator friendly?

Now that you know the API types you want to use, you need to ensure your menu is compatible with third party food aggregators. Your menu must be online ordering friendly and structured in a way that it can be pushed through to food aggregators. Refer the specifications to structure it properly. Menu APIs can be used to push your menu into Grubtech only when these specifications are met.

For more information refer the section on Menu Integration. If your menu is not food aggregator friendly refer the section on Menu Items Integration.

When do you like to receive an order?

  • Receive an order when Grubtech receives it?
  • Receive an order when Grubtech accepts an order?
  • Receive an order when Grubtech completes an order?
  • Receive an order when Grubtech dispatches an order?

On what status can Grubtech send a full order payload?

For example: If you start getting orders when Grubtech receives it, you need to listen to the accept/reject status updates and filter these orders appropriately.

If you start getting orders only when they are accepted by Grubtech, you will only receive orders that Grubtech accepted. If you are going to receive orders when it is accepted, you have to implement cancellation notification as an order can be cancelled even after acceptance. /Orders and /Cancellation endpoints are required for this type of integrations.

The advantage of receiving the payload at the final stage is that cancelled orders being pushed through will be greatly reduced.

The statuses mentioned above are the status that Grubtech currently offers. You need to decide at which point should Grubtech push the order based on your requirements. Once you receive the order based on the KDS system that you are using the rest of the status updates can flow either way. This means you can receive notifications based on the event and if you are managing the lifecycle, you must send the status back to Grubtech.

For example: if you decide to use the Grubtech KDS, Grubtech will send the status updates to your POS system if you require it (which is optional). However, the cancellation notification is a must.

NOTE: If you’re using your own POS system, you have to send Grubtrech certain status updates. For example: the order prepared is mandatory.

Order Started

Once you receive the order, the status update flow is decided based on whether you use the Grubtech KDS or your own KDS system.

This is only applicable if you (third-party) are using your own KDS System. If so, you can send the different status updates. If you handle a manual acceptance, you can send an accept or reject API call.

If you support marking an order as started, you can send Grubtech the API call.

KDS applications do not have a button to press or indicate that the order preparation has started. If it is supported, you must send a notification or Grubtech can configure an order to ensure it is started automatically.

For certain food aggregators, Grubtech sends a notification saying we have started preparing the order and the order is moved to order prepared.

In order prepared, if you’re using the KDS system, it is required that you notify Grubtech. It is not possible to automatically prepare an order.

Order Acceptance Webhook

If you want to handle order acceptance on your POS system you need to implement those end points and you have to receive the order payload on creation.

For all orders, Grubtech generates invoice numbers. However, if you receive the order when it is created on the Grubtech platform, an invoice number will not be generated. Grubtech only generates the invoice number after acceptance.

Who manages the acceptance of an order?

Order Acceptance Scenarios

  • Order is accepted automatically by Grubtech
  • Order is accepted manually from the Grubtech KDS
  • Order is accepted manually by the third-party POS system

If you are going to decide to accept manually on your third-party POS system then there is a hard time limit. You must send an accept notification within 90 seconds. If not, Grubtech will send an accepted notification back to the upstream systems stating the order is accepted.

Recommendations

We recommend that Grubtech is allowed to accept orders automatically as there are some hard time limitations with food aggregators. If you do not send an accept notification during the specified time limitation, the food aggregator will reject the order. This in turn will impact your brand and restaurant.

How are you going to accept orders?

Are you going to accept orders on your side or opt for auto acceptance?

The order lifecycle

  1. The user places an order.
  2. The order platform forwards the received order to Grubtech.
  3. Grubtech invokes the POST - Order endpoint to push the order to your platform.
  4. The server successfully processes the request.
  5. The POS application accepts the order.
  6. The server successfully processes the request
    Or
  7. The POS application rejects the order.
  8. The server successfully processes the request.
  9. The order accepted/rejected status is sent by Grubtech to the order platform.
  10. The order is started by the POS application.
  11. The server successfully processes the request.
  12. The order started status is sent by Grubtech to the order platform.
  13. The POS application prepares the order.
  14. The server successfully processes the request.
  15. The order prepared status is sent by Grubtech to the order platform.
    Or
  16. The POS application cancels the order.
  17. The server successfully processes the request.
  18. The order cancelled status is sent by Grubtech to the order platform.

What are the different validation requirements that need to be updated on Grubtech?

Things to remember

  • Accept/Reject API - calls depends on whether it is manually accepted or not.
  • Started API - call orders depends on whether there is a button to press from the KDS or POS system.
  • Order prepared – it is mandatory to send Grubtech a notification if you’re using your own KDS.
  • Auto prepared – Started and prepared can be configured as automotive, if you’re using your own KDS and you don’t have the capability to capture these status updates on your system. Grubtech needs to send these status updates to certain food aggregators.

To manage the order lifecycle at your end, you must send the sequential status to Grubtech.

What do you do if you need to go live with new brands or new locations after the initial go live?

For example: you have your go live in January. In March you need to add 2 new brands and 2 new locations. What is the process for doing this? Can this be done automatically? What are the implications of that? What are the steps for doing this integration manually?

If you want to connect a new location you must access Grubcenter and connect the location through our interface. Grubtech will issue a store ID for your location and brand. This store ID must be configured from your end. There is no automated process. You must visit Grubcenter, configure the new location, copy the store ID issued by Grubtech and configure it on your end.

You can also opt to connect a location through our customer support team.

How the order payloads look like

Examples:

  1. Scenario 1: Order with both item level and separate order level discount. The payment discount value is a total of the item discounts and includes the order discount as well.
    https://sample-payload.s3.eu-west-2.amazonaws.com/762519710115219296.txt

  2. Scenario 2: Order with order level discount. Item level discount values are set to 0.
    https://sample-payload.s3.eu-west-2.amazonaws.com/852517853256036352.txt

  3. Scenario 3: Order with order item level discount. Sum of the item level discounts are equal to the value in payment.discount value.
    https://sample-payload.s3.eu-west-2.amazonaws.com/852518252397350912.txt

NOTE: Please note that not all order channels support item-level discount.

Do you need information in real-time for operations or do you need data in a periodic manner for reporting and analytical purposes?

For Realtime – Use Order APIs

To get real-time data for operational purposes on your POS or ERP system, use:

  • POST/orders
  • POST/orders/{id}/started
  • POST/orders/{id}/accepted
  • POST/orders/{id}/rejected
  • POST/orders/{id}/prepared
  • POST/orders/{id}/completed
  • POST/orders/{id}/dispatched
  • POST/orders/{id}/cancelled

For reporting and analytics use Data APIs

To get data on past orders in bulk or get data based on the order ID use:

  • GET/orders/
  • GET/orders/{orderID}

Do you have support to receive orders in real-time?

If yes, it means there is a button or some kind of mechanism to accept the order on their POS. You must send it to the Grubtech API for which this order is accepted.

For publicly accessible webhook services:

If you cannot accept notifications from Grubtech when using the Grubtech KDS, once an order is accepted Grubtech can send the accept notification to you.==

Do you have a webhook to give updates in real-time?

If yes, use the Order APIs. If not, Grubtech can push orders from food aggregators.

When you place an order in the ordering platform. That order comes to Grubtech.
Since the external POS system exposes the URL which is a required feature, once the order is created in the Grubtech platform, Grubtech will push the order to the external system. If you are managing your order lifecycle on your POS, you can send a notification to Grubtech using the Grubtech notification end points.
If you are using the Grubtech KDS, it means Grubtech can push notifications to your POS using your webhooks.

Updated about 2 months ago