Petpooja and Tuckly

Why a Petpooja connection matters

If your kitchen runs on Petpooja, every order that arrives from somewhere other than Petpooja itself has to be entered into Petpooja before it prints a KOT and shows up in the day’s sales. For most Indian restaurants that already covers the marketplaces, because Petpooja lists Swiggy, Zomato, Uber Eats and others among its online-ordering integrations. A direct order from your own website is the odd one out until it has the same path in.

That is the job this integration would do. The order a customer places on your Tuckly site would land in Petpooja the way a marketplace order does, and the menu would stay in step between the two.

What Petpooja’s API makes possible

Petpooja publishes documentation for its online-ordering integration API. Its own description is that the platform lets a restaurant partner manage store, menus and orders received from an online ordering channel. In plain terms, the documented pieces are:

• Push menu. Petpooja sends the menu to the partner whenever it changes, so an item renamed or repriced in the POS reaches the ordering site without anyone re-entering it.
• Fetch menu. The partner can also request the current menu on demand.
• Save order. An incoming order is written into Petpooja in a pending state until the restaurant accepts or rejects it on the POS.
• Order callback and status updates. Petpooja reports back when the order is accepted, rejected or marked food ready, and the partner can update status in the other direction.
• Rider information webhook. Rider details Petpooja has for an order can be sent to the partner.
• Item stock on and off, and store status. Sold-out items and a closed outlet can be reflected on the ordering side.

Authentication uses an application key and an access token. Credentials for both staging and production are provided by Petpooja’s team, and Petpooja invites prospective integrators to contact it to join its programme. There is no self-serve sign-up, which is the main reason this page says contact us rather than available.

The flow we would build

Picture a Tuesday evening. A regular orders a thali and two rotis from your site. Today, that order shows on the Tuckly order screen and somebody at the counter keys it into Petpooja so the kitchen gets a KOT and the sale is recorded.

With the integration in place, the order would appear in Petpooja’s pending queue within moments of payment. Staff accept it on the POS as they would any aggregator order. The KOT prints. When the kitchen marks it ready in Petpooja, the status flows back to Tuckly and, for a delivery order, you move on to booking a rider through Porter or your own team.

Menu changes would run the other way. Take the paneer tikka off in Petpooja because the stock did not arrive, and it disappears from your ordering site. Add a weekend special, and it shows up without a second entry.

What would still be manual

The pending state is deliberate on Petpooja’s side, and it means a person still accepts each order. That is a feature, not a gap: it keeps a kitchen from being committed to food it has not seen. Preparation time, rider booking and the conversation with a customer whose address is unclear all stay with your staff.

Payment reconciliation is also outside this integration. Your payment gateway settles direct orders to your bank, and Petpooja records the sale. Matching the two is a bookkeeping task that an order push does not perform.

Is it worth waiting for?

If you take a handful of direct orders a day, retyping them is a nuisance rather than a cost. If you take dozens, the double entry starts to show up as mistakes and delays during the rush, and the integration earns its place. Either way, taking direct orders does not have to wait for it. Many restaurants start with the online ordering system on its own and add the POS link once volume justifies the setup work on both sides.