Order acceptance
All ezCater orders, integrated or not, must be accepted in Partner Portal before anything else happens. Acceptance is the gate that triggers transmission to Olo.
How acceptance works
When a new order arrives:
Your team is notified by email, SMS, or iOS push notification, depending on which channels your store has configured
The notification links into the Partner Portal, where the order details are visible
A team member reviews the order and clicks Accept. This single action commits your store to fulfill the order
If a store hasn’t yet onboarded the Olo Rails integration, ezCater walks the team through the acceptance workflow as part of onboarding, along with reminder notification settings and escalation paths.
Accepting the order is the commitment to fulfill it. Once accepted, the order is yours to deliver — whether transmission to Olo succeeds or fails. See Operational Practices for what to do if transmission fails after acceptance.
Order transmission
The instant a team member accepts the order in Partner Portal, ezCater transmits it to Olo Rails. There’s no batching, no scheduled run, no delay — acceptance triggers transmission directly.
What happens after transmission
Once the order reaches Olo Rails:
It sits in a scheduled state in Olo, visible to your team in the Olo interface.
Olo’s Fire to POS setting determines when the order fires to your POS.
The fire timing is governed by lead time in Olo Rails, configured by your brand or your Olo rep.
The order’s lifecycle inside Olo is entirely Olo-managed at that point. ezCater hands the order off; everything from “received by Olo” through “received by POS” is Olo’s responsibility. If you need to adjust fire timing or lead times, work with your Olo rep — the configuration lives in Olo, not in ezCater.
What orders are supported
The Orders API transmits ezCater Marketplace, Online Ordering, and Meal Program orders. Off-menu items and direct-entry orders are not supported and continue to require manual handling outside the integration.
What data is transmitted
The Orders API passes the data Olo needs to route the order through to your POS. Specifically:
Data | Included? | Notes |
Menu items and selections | Yes | Based on mapped IDs between ezCater and Olo Rails |
Fulfillment date and time | Yes | Customer’s requested event time, not driver pickup time |
Customer name | ezCater | All orders show ezCater as the customer; the actual guest’s name is in Partner Portal |
Customer email | ezCater-generated | An ezCater email referencing the order number, not the guest’s personal email |
Customer phone | No | Guests are reached through ezCater Customer Support |
Delivery address | Yes | For self-delivery and dispatch orders |
Delivery fee | Yes |
|
Delivery time | Yes |
|
Delivery instructions | Yes |
|
Tip | Yes |
|
Promotions, Preferred Partner Program rewards, commissions | No | Not passed through; you receive the value of the order to the guest in Olo |
The time shown in Olo is the customer’s requested event time, not the driver pickup time. To verify pickup and delivery times, use Partner Portal — those details are surfaced there
Order fire to POS
When the order fires from Olo Rails to your POS is controlled by Olo’s lead time configuration. ezCater does not control or influence the fire timing.
For specifics on your store’s fire timing, work with your Olo rep. Common questions Olo can answer:
What is the current lead time setting for this store?
Do all advance orders fire at the same time, or staggered by event time?
How does the lead time interact with our throttling configuration?
