DSP Feature Flags
Your DSP integration starts with a standard set of behavior. On top of that, Stream maintains a small number of feature flags — optional capabilities that can be switched on for your integration specifically, so you only implement and receive what your platform actually supports.
This page is the complete list of what exists for DSP integrations. Each entry states what changes when the flag is on and what your platform has to implement to support it.
| Capability | Default | What it changes |
|---|---|---|
| Item-level menu updates | Off | Receive targeted object updates instead of a full menu republish |
| Menu schema version | v1 | Receive the flattened v2 menu payload instead of the nested v1 payload |
| Managed inactive entities | Off | Receive inactive items, item families and modifiers rather than having them stripped |
| Unpaid pickup orders | Off | Permits your platform to submit unpaid pickup orders |
| Unpaid delivery orders | Off | Permits your platform to submit unpaid delivery orders |
| Busy Mode events | Off | Receive location.busy events when a merchant marks a location busy |
How feature flags work
A few rules apply to every flag on this page:
- Everything is off by default. An integration with no flags enabled is a valid, complete integration — flags only add behavior. If you never request one, nothing about your integration changes.
- Flags are enabled by Stream, not self-service. There is no API for turning a flag on. Ask your Stream contact for the capability by name and we will enable it against your integration.
- Enabling requires your integration to be live. A capability can only be switched on once your
integration status is
live. While you are still inbuildingorpilot, plan your build around the flag but expect it to be enabled at go-live. Turning a capability back off is always possible, at any status. - Flags apply to your whole integration, not per merchant or per location. Once enabled, the behavior applies to every location connected to your platform.
There is currently no endpoint that returns which flags are enabled on your integration. If you are unsure what you have, ask your Stream contact and we will confirm.
POS and Events integrations have their own capabilities — see POS Feature Flags and Events Feature Flags.
Item-level menu updates
Default: off — every catalog change on Stream results in a full menu republish.
When enabled, a change to an item, item family or modifier is sent to your /v1/event endpoint as a
location.update event carrying only the changed objects, instead of triggering a complete
republish. This avoids rebuilding an entire menu to 86 a single item.
What you need to implement: a handler for the location.update event. See
Menu Object Updates
for the payload.
Two things are worth knowing before you build it:
Not every change is eligible
Category, modifier group and tax changes are never sent as object updates — those always fall back to a full menu publish, whether or not this flag is on.
Partial support is safe
If your endpoint returns a 404 for an update you do not handle, Stream falls back to a full menu publish for that change. You can implement the update types that matter to you and let the rest degrade gracefully.
Menu schema version
Default: v1.
The v2 menu schema is a flattened, association-based structure: menus, categories, item families, items, modifier groups and modifiers are sent as separate top-level collections cross-referenced by id, rather than nested inside each menu. An item that appears on several menus is sent once instead of duplicated per menu, which meaningfully reduces payload size for large catalogs.
What you need to implement: parsing for whichever schema you opt into. See Menu Schemas.
This is an independent choice — the object-update payload above is identical in both versions.
Managed inactive entities
Default: off — anything inactive is excluded from the menu Stream sends you.
When enabled, Stream stops removing inactive objects from the published menu and sends them with
is_active: false instead, leaving your platform to suppress them. You choose which of the three
object types this applies to: items, item families, and modifiers. Categories, modifier
groups, taxes and bundles are always pruned and cannot be included.
What you need to implement: your own handling of the active state, so that an inactive object is not orderable on your platform.
The main benefit is avoiding menu rebuilds: an item that is present-but-inactive can be resumed with a targeted update rather than a full republish. See Active / Inactive Item and Modifier Handling.
Unpaid pickup orders
Default: off.
Permits your platform to submit pickup orders marked as unpaid — orders where your platform has
already collected payment, or where the customer pays in store. Without the flag, an unpaid pickup
order is rejected with a payment failure.
What you need to implement: send the unpaid indicator, with the cash-to-collect amount in minor units, on the orders that need it.
Unpaid delivery orders
Default: off.
The same mechanism for delivery and merchant_managed_delivery orders, with one addition: the
merchant must also have enabled unpaid delivery orders on their own location. Both must be true
or the order is rejected.
What you need to implement: the same unpaid indicator as above. The merchant-side setting is not something your platform controls — if orders are still rejected with the flag enabled, that setting is the thing to check.
Unpaid dine_in, drive_thru and curbside orders are always accepted and need no flag.
Busy Mode events
Default: off.
When enabled, a merchant marking a location as busy sends your platform a location.busy event with
an absolute prep time to surface and a busy_until timestamp to self-expire against. Clearing busy
mode early sends a follow-up with the feature disabled.
What you need to implement: a handler that raises the quoted prep time until the expiry, then reverts. See Busy Mode.
Directory listing metadata
Not a flag, but the one piece of optional configuration you control directly: your listing
description and category determine how your platform appears to merchants in the "connect a
delivery service" directory. Both are set through the Partner API and take effect without Stream
involvement. Categories are marketplace, online_ordering, ai_ordering and kiosk.