Skip to main content
Fulfillment is how a customer receives their order. It is not the menu and not the app they ordered from — it is the promise: we will bring it to your door, you will pick it up, we will serve it at the table, or another flow you define. You create fulfillment options in the Fire spark dashboard. Each option has a type. Pick the type that matches the last step for the customer — where the food actually changes hands — not the channel they used to order. Someone can order drive-thru from your app.
Delivery fees, tips, and similar checkout extras attach to a fulfillment option. They are not fulfillment types on their own.

​
Fulfillment types

These are the types you can choose when you create a fulfillment option. In the dashboard the type names appear as DELIVERY, PICKUP, TAKEOUT, DINE_IN, DRIVE_THRU, CURBSIDE, TABLESIDE, and OTHER.
Use delivery when a courier — your fleet, a partner, or an aggregator — takes the order to an address. The customer expects a drop-off, not a visit to the store.
Use pickup when the customer comes to the store to collect an order they already placed, often ahead of time. The bag is ready at a shelf, locker, or counter window.
Use takeout when the customer is already at the venue — kiosk or counter — and leaves with the food. It is the in-store to-go path, not scheduled collection from the app.
Use dine-in when the customer stays and eats. Restaurants run this in more than one way: table service, pay-first counter (QSR), or kiosk then a table number. Choose the starting flow that matches the store.
Use drive-thru when the customer receives the order at a lane window. Payment is typically collected after handoff at the window. Offer it only at stores that have a lane.
Use curbside when the customer parks and stays in the car. They pay before the kitchen starts. Staff then brings the order to the parking spot. Same idea as drive-thru, without a window — and payment happens first.
Use tableside when serving at the table is its own option — for example next to takeout at the same store. The customer pays first, then sits down and is served.
Use other when your promise does not fit the types above. You still name the option and decide which stores and channels show it.

​
Starting flows

When you pick a type, Fire spark suggests a starting flow: when the kitchen begins, when you hand the order to the customer, and when you collect payment. You can change that flow. Dine-in and takeout offer more than one starting flow because restaurants run those differently (table service vs pay-first, kiosk vs counter).

​
Rules per store, channel, and type

Fulfillment rules can vary per store and per channel. A location might offer delivery on your app but pickup-only on an aggregator. Drive-thru might exist only at locations with a lane; curbside on web but not on kiosk. Fire spark keeps those rules in one place so each surface shows only what that store can honor.

​
Why this matters commercially

Misconfigured fulfillment causes the most visible failures: the customer expects delivery, the store prepared pickup; an aggregator shows a service the kitchen cannot run. You can try a new handoff mode or turn a type on in one region without a new integration. You define the type, its flow, and where it is live.

​
Operations handoff

When an order is placed, the fulfillment type and any related charges travel with it into your POS or RMS. Kitchen and dispatch stay in the systems your team already uses; Fire spark carries the customer’s choice from channel to counter.

Orders

Purchases with a fulfillment type

Stores

Where fulfillment happens

Channels

Surfaces that expose fulfillment options

Fulfillment workflows

Nodes, callbacks, Release checkout, and order.changed