Delivery partner integrations, explained without the logo wall

Questions to ask any ordering platform about delivery integrations

Delivery integrations are where ordering platforms most often overstate. A logo on a page can mean anything from a tested workflow to a conversation that happened once. These questions separate the two.

Which parts are automated, and which are a person?

Ask specifically about quote, booking, status updates and tracking. “We integrate with X” should decompose into four answers. If the answer to all four is “the restaurant does it in the partner’s app”, that is not an integration, it is a tab in a browser. It may still be fine for you; it just should not be sold as more.

In which cities, with which vehicles?

Delivery partners do not cover everywhere, and their APIs sometimes cover less than their apps. Porter, for example, publishes its API for two-wheelers while its app offers larger vehicles too. Ask for the list of cities where the automated workflow has actually run.

What happens when a rider is not available?

The failure case decides whether an integration helps or hurts on a busy night. Does the order screen show that no rider was found, within how long, and can the restaurant switch the order to another method in one step? A platform that cannot answer this has not run the integration in a monsoon.

Who holds the partner account, and who gets the invoice?

With most delivery partners the restaurant holds its own account and pays per trip. Some platforms resell delivery and add a margin. Neither is wrong, but you should know which you are getting and what the margin is.

Can the restaurant still choose per order?

An integration that forces every delivery order to the partner removes your cheapest option on the nights your own rider is standing there. Per-order choice is the feature to insist on.

What does the customer see?

Status stages, a tracking link, a rider’s name and phone number, or nothing. All three are possible; ask which.

Has it been validated, and will you say so in writing?

A platform willing to label a workflow “pending validation” on its own site is telling you something about how it will behave when the integration breaks at 8pm. The delivery management page is our attempt at that standard.

How to read an integrations page

Look for a status per capability rather than a status per logo. “Porter: available” tells you almost nothing; “booking: pending validation, manual booking: available, tracking: pending validation” tells you what will happen on Friday. Look for a date on the page, because partner APIs change and a page nobody has reviewed in a year is describing a product that no longer exists. And look for a list of cities, since a delivery partner integration that works in three cities is a three-city feature however it is described. Our integrations directory is organised that way for a reason.

Why integrations stay in validation longer than demos suggest

A demo books one rider on a Tuesday afternoon in a city with plenty of them. Live service means a hundred orders on a Friday, three of them to addresses the partner’s map does not recognise, one rider who cancels after pickup, and a webhook that arrives twice. Each of those is a small piece of engineering, and each one has to be seen in the wild before it can be called handled. That is why the honest status of an integration lags the marketing version, and why we would rather publish the lag than hide it.

For what the whole fulfilment picture looks like, including pickup and your own riders, start with the delivery management page. For the first weeks of running delivery from your own site, the guide to offering delivery and pickup from your own website is the practical companion.