Skip to main content
A flow is not limited to text. The send_amb_primitive node emits a native Apple Messages for Business primitive — a real list picker or time picker rendered by the Messages app, not a numbered list the customer has to type a reply to. This is what separates a flow on AMB from a flow on SMS. The customer taps; the reply comes back structured.

​
All eight primitives appear in the picker

Each is configured on the node with a primitive_type and the primitive’s own payload. For the first five, the payload shape is exactly the one documented in Rich Feature Messages — a flow does not use a different schema.
Apple Pay, OAuth, and iMessage Extension are coming soon. All eight primitives have a backend builder, so a node set to any of them is technically valid — but these three have no configuration modal. A node you can’t configure sends nothing at runtime, silently. Build with the other five until a modal ships for these three.That gap tracks a reasonable boundary rather than an oversight: taking a payment, authenticating someone, or handing off to a custom app surface are decisions that want context and judgement. Until these three are configurable, reach a point like that with assign_to_agent and let the AI agent — or a human — take it from there.

​
Use List Picker where the answer matters

Worth repeating here because it bites in flows specifically. Quick replies on Simple Message return only their label text — the key you set does not come back. A branch_on_reply node matching those branches is effectively matching on visible copy. So a copy change to a quick reply can silently break the branch that depends on it, and localisation multiplies the problem.
If a branch_on_reply depends on the choice, send a List Picker rather than quick replies. It returns dependable identifiers, so the branch survives a copy change. Reserve quick replies for low-stakes two-or-three-option prompts.
See Known limitations.

​
Other channels

send_amb_primitive is Apple-specific. On other channels a flow sends text via send_message, and the channel renders whatever it renders.
Design the fallback, not just the best case. A flow that only makes sense with a rendered List Picker degrades badly on SMS. If the same flow can trigger on more than one channel, put the essential information in text and let the rich primitive enhance it.

​
Next

Rich Feature Messages

All eight primitives, their payloads and constraints.

Node types

The full node set, including what is not yet available.

Branching and variables

Matching on a reply, and what survives a copy change.

Testing and simulation

Verifying a primitive renders before a customer sees it.