MENA restaurants, grocers, and dark stores running on Talabat live in two systems at once. Orders land in the Talabat vendor portal or a Talabat-provided tablet, while inventory, purchasing, kitchen costing, and accounting sit in ERPNext. Someone re-keys each order, stock counts drift the moment a busy lunch rush hits, an out-of-stock SKU keeps selling because nobody updated the Talabat menu, and at month-end the finance team squints at a Talabat settlement report trying to match payouts and commission against sales that were never booked in ERPNext. ERPNext core has no native concept of a Talabat channel — there is no order source, no menu-publish target, and no settlement matcher out of the box — so the gap gets filled with spreadsheets and overtime.

We build a dedicated Frappe app — a proper installable app with its own module, DocTypes, and hooks.py wiring — that treats Talabat as a first-class sales channel inside ERPNext. Incoming Talabat orders are pulled via the Talabat Integration Platform and materialized as native Sales Order / Sales Invoice documents (or POS Invoices for dark-store flows) against a dedicated Talabat customer and price list, with a Talabat Order link DocType retaining the raw payload, external order id, branch, and status for traceability and idempotent replays. Menu publishing runs the other direction: your ERPNext Item records (with an Item Group → Talabat category mapping and a per-branch availability child table) are transformed and pushed to your Talabat catalog, so the menu customers see is driven by the same master data your kitchen and purchasing teams already maintain.

Technically, order intake is handled by whitelisted methods exposed over the Frappe REST API for webhook callbacks plus scheduled bench poller jobs registered under scheduler_events for reconciliation and retry, so nothing is lost if a webhook is missed. hooks.py document events (for example on_update / on_submit on Item and Stock Ledger Entry) trigger stock and availability pushes to Talabat when quantities cross the availability threshold, debounced through the background queue so a busy period doesn't hammer the API. Order-status and rider-handoff transitions map cleanly onto ERPNext status fields and a status-history child table, driven by server scripts and reflected in the agent UI via client scripts. A Talabat Settings single DocType holds credentials (stored encrypted), branch/store mappings, tax and commission configuration, and toggles; a dedicated role profile and permission rules keep channel operators out of the rest of your ledger. Every integration event is logged for audit and safe reprocessing, and the app targets Frappe/ERPNext v15 and v16.

Because this is build-to-order, nothing ships blind. We start with a short scoping call to confirm your Talabat account type, branch topology, menu structure, tax setup (VAT by market), and how you want settlements reconciled. We then build against your exact ERPNext version and item model, ship the source to a staging site for UAT, and only go live once you have signed off — typical delivery is 2–4 weeks from confirmed scope. You receive the installable app source, a git repository handover, install and configuration on your infrastructure, technical and user documentation, a training session, and a post-go-live support window with a documented rollback plan.