How I Built OrderBridge: Solving the Delivery-to-POS Connection
A few months ago, a client came to me with a problem that was simple to describe and it seemed quite straightforward. They needed to bridge the gap between major delivery platforms and their own POS system with an automated OAuth 2.0 handshake.
This project started as a real client brief. The request came in Spanish: "Queremos conectar los servicios de domicilios de nuestros clientes (DoorDash, etc.) a StreamOrder utilizando OAuth. Una vez que StreamOrder esté conectado y autenticado, las cuentas de los servicios de entrega de los clientes se conectarán a nuestro sistema POS."In short: they needed to connect their clients' delivery accounts to their POS system through StreamOrder's partner API — automatically, via OAuth, with no manual intervention. I analysed the requirements, read through the StreamOrder partner documentation, and got to work.
The Client Proposal
Before writing a single line of code, I put together a formal proposal. It forced clarity on both sides — the client understood exactly what they were getting, and I understood exactly what I was building.
PROJECT PROPOSAL
Delivery Apps to POS Integration
Middleware API · StreamOrder · OAuth 2.0
Maximiliano B. Torres
February 27, 2026
DESCRIPTION
This project establishes a secure, automated “Digital Bridge” — a Middleware API between the StreamOrder aggregator and the client's Point of Sale (POS) system, enabling delivery orders to flow automatically into the POS with no manual intervention.
OBJECTIVE
Implement OAuth 2.0 as the authentication layer, ensuring data remains secure while allowing orders to sync automatically from delivery platforms into the POS.
ARCHITECTURE FLOW
4-Week Timeline
Week 1
Security & The Digital Handshake
Goal: Securely connect the client accounts.
Result: StreamOrder officially linked; data protected by encrypted OAuth keys.
Week 2
The Automation Bridge
Goal: Make the systems communicate.
Result: Translator and webhook listener live in a test environment — orders captured and translated instantly.
Week 3
Dashboard & Live Launch
Goal: Visibility and production readiness.
Result: Bridge active, orders printing in the POS, live monitoring dashboard delivered.
Week 4
Refinement & Monitoring
Goal: Stability under real-world conditions.
Result: 7-day live monitoring window; API changes from StreamOrder or delivery platforms patched immediately.
Core Deliverables
PROJECT PREREQUISITES
Keeping Track of All the Orders
Before we automated this, the workflow was boring and painful. Most busy kitchens have a counter full of tablets from different delivery apps.
A staff member has to:
- Read the order off a tablet.
- Manually type it into the POS.
- Hope they didn't miss a "no onions" modifier or something.
In a quiet shop, it's boring. In a kitchen doing 80+ orders a day, it's a painful operational problem.
THE MATH
50 orders a day × 2.5 minutes of manual entry × $18/hr = $1,100+ lost every month to a task that shouldn't involve a human at all.
Engineering the Pipeline
Once the ROI was clear, I mapped out the pipeline. The logic needed to be bulletproof:
Ingest delivery webhooks
Receive HTTPS POST from each delivery platform.
Verify signatures
HMAC-SHA256 check — security before anything else.
Translate schemas
Map disparate JSON payloads into a unified POS format.
Inject the order
POST to the POS API with exponential-backoff retry.
Broadcast updates
WebSocket push to the live dashboard — no polling.
Writing the Spec First
I started with a Software Requirements Specification (SRS) before writing a single line of code. It's much easier to fix a mistake in a document than to rewrite production code later. The SRS forced both me and the client to agree on exactly what “done” looked like — no ambiguity, no scope creep.
System must act as an OAuth 2.0 provider — issuing, validating, and refreshing tokens per RFC 6749.
System must accept HTTPS POST webhooks from delivery platforms and verify each request with HMAC-SHA256 signature validation.
System must map all incoming delivery payloads to a unified POS format, with graceful failure and logging on unmapped SKUs.
System must POST translated orders to the POS API with exponential-backoff retry on failure — no order dropped silently.
Dashboard must reflect order status changes via WebSocket push. No polling.
OAuth tokens must survive server restarts, stored encrypted at rest.
The Tech Stack
What tools would I use for this kind of project:
I am sure that Python would've also worked wonders here. Personally I prefer working with node modules and npm over pip and virtual environments.
Express is the legacy default, but Fastify is built for modern performance. Built-in JSON schema validation, lower overhead. For a middleware API where every millisecond counts, Fastify wins.
Infrastructure
The three services are independently deployed — each with its own host, its own domain, and its own responsibility. This mirrors how a real production integration would be structured.
INFRASTRUCTURE OVERVIEW
Real-time monitoring UI — edge-deployed, globally available.
Core middleware engine with the OAuth server, webhook ingestion, schema translator, and POS injector. PostgreSQL stores OAuth tokens, menu mappings, and order logs.
Isolated POS simulator running as a completely separate service — its own OAuth consent flow, its own order terminal.
WHY SEPARATE SERVICES
Keeping MockPOS on its own Railway service wasn't just convenient — it was the point. It proves the integration works across a real network boundary, not just between two functions in the same process.
Translation and Trust
The Translator was the hardest part of this project. DoorDash, Uber Eats, and GrabFood all have wildly different ideas of how to describe a "Cheeseburger with no pickles." Mapping these inconsistent payloads to a standardised POS SKU while maintaining a MenuMapping table required deep edge-case handling. If the mapping fails, the system has to fail gracefully — not drop the order into a void.
Then there was the OAuth 2.0 Server. It's one thing to use OAuth; it's another to be the provider. Building the authorization endpoints, token logic, and encrypted storage according to the RFC specs took more gray hair than the rest of the app combined.
Introducing OrderBridge
I enjoyed the architecture of the client project so much that I built OrderBridge — a refined, standalone version for my portfolio. It's not just a copy; it's an evolution. A complete end-to-end demo that simulates the entire flow without needing real-world infrastructure.
The Complete Codebase
All three core components are open-source and available on GitHub:
Try It Out
Both services are live and ready to use:
Ready to Explore?
Dive into the source code, watch the live systems in action, or check out the full case study.