How Temperô integrated iFood orders into its restaurant SaaS — and the bugs found along the way

Temperô, a multi-tenant restaurant management SaaS built on Node/TypeScript and PostgreSQL, set out to automatically route iFood marketplace orders into its internal kitchen, payment, and delivery workflows without requiring staff to operate two systems simultaneously. Because iFood does not support inbound webhooks, the team implemented a polling mechanism that calls iFood's Order API every 15 seconds using a flag-guarded setInterval loop to prevent overlapping executions. The platform adopted iFood's 'Centralised' credential model — a single OAuth2 client_credentials token filtered per merchant — which required mid-project refactoring of the token cache from a per-unit to a shared in-memory store. Version one of the integration covers delivery orders only; takeout and dine-in requests arriving via the marketplace are automatically cancelled, and menu items are ingested using name and price directly from the payload rather than being mapped to Temperô's internal catalogue. The article also details a prolonged investigation into why cancellation-confirmation events occasionally never arrived, tracing the issue to subtle differences between the iFood event fields 'code' and 'fullCode'.