Meta
Confirm which brand your key belongs to, and list the part types this API supports.
Get the part registry
ModelsExpand Collapse
PartInfo object { token, interactive, label, 11 more } One member of the sealed part union, described for a composer.
One member of the sealed part union, described for a composer.
The capability-list token a device must announce, same value as capability_token. EMPTY means universal; not “unknown” and not “blocked”: disable a type only when this is non-empty and the token is missing from the chat’s capabilities.
Whether the part renders as an interactive message (Apple’s interactiveData family plus the payment, auth and app balloons).
What a composer calls this type in front of a human. Served rather than hardcoded client-side so the name has one home.
This type’s JSON Schema 2020-12: the same authority document GET /v1/parts/{type} publishes byte-verbatim, embedded here as JSON so one request equips a composer for every type.
The capability-list token a device must announce for this part to render. ABSENT means universal: disable a type only when this field is present and the token is missing from the chat’s capabilities. Kept alongside token, which carries the same value: the long name shipped first and a client may already read it.
What a customer sees when this part degrades, or why it never does. Present for every capability-gated part, and read together with degrades_to: a note WITHOUT degrades_to means the part is never substituted and the note says why (an unsupported send is refused, not rewritten); a note alongside degrades_to describes the substitution. An empty target list is never served: absence of degrades_to is the signal.
The POSSIBLE part types this one can become under degrade:"auto" when its token is not announced, richest first. Informational, not device-resolved: which one a given customer gets depends on the rest of their announced capabilities, so preview the message against the chat for the answer a specific device would produce. Absent for universal parts, and for gated parts that are never substituted; degrade_note tells that story either way.
Which devices render this type, as prose from the OS-capability matrix; e.g. iPhone, iPad or iPhone, iPad, Mac.
Where this row is sourced in Apple’s canonical documentation, as line references.
Minimum iOS/iPadOS version, e.g. 18.4. Every type has one; AMB is an iOS-first channel, so this is always present.
PartRegistryResponse object { parts, rules } The part registry: the union, its capability gates, and every enforced rule.
The part registry: the union, its capability gates, and every enforced rule.
The capability-list token a device must announce, same value as capability_token. EMPTY means universal; not “unknown” and not “blocked”: disable a type only when this is non-empty and the token is missing from the chat’s capabilities.
Whether the part renders as an interactive message (Apple’s interactiveData family plus the payment, auth and app balloons).
What a composer calls this type in front of a human. Served rather than hardcoded client-side so the name has one home.
This type’s JSON Schema 2020-12: the same authority document GET /v1/parts/{type} publishes byte-verbatim, embedded here as JSON so one request equips a composer for every type.
The capability-list token a device must announce for this part to render. ABSENT means universal: disable a type only when this field is present and the token is missing from the chat’s capabilities. Kept alongside token, which carries the same value: the long name shipped first and a client may already read it.
What a customer sees when this part degrades, or why it never does. Present for every capability-gated part, and read together with degrades_to: a note WITHOUT degrades_to means the part is never substituted and the note says why (an unsupported send is refused, not rewritten); a note alongside degrades_to describes the substitution. An empty target list is never served: absence of degrades_to is the signal.
The POSSIBLE part types this one can become under degrade:"auto" when its token is not announced, richest first. Informational, not device-resolved: which one a given customer gets depends on the rest of their announced capabilities, so preview the message against the chat for the answer a specific device would produce. Absent for universal parts, and for gated parts that are never substituted; degrade_note tells that story either way.
Which devices render this type, as prose from the OS-capability matrix; e.g. iPhone, iPad or iPhone, iPad, Mac.
Where this row is sourced in Apple’s canonical documentation, as line references.
Minimum iOS/iPadOS version, e.g. 18.4. Every type has one; AMB is an iOS-first channel, so this is always present.