# Use Apple Invitation Messages correctly

Prepare an approved Apple invitation, retain explicit customer consent and distinguish submission status from customer acceptance and conversation activity.

## Prerequisites

Connect your Apple Messages business in Bird and obtain Apple’s separate invitation approval for the business and template. Prepare a service journey that captures explicit opt-in for the defined purpose. Apple also requires compatible versions on every device linked to the recipient’s Apple Account; check the current [Invitation Messages requirements](https://register.apple.com/resources/messages/msp-rest-api/business-updates) before testing.

## 1. Define the permitted invitation purpose

Choose a supported continuation such as moving an existing support request into Messages. Invitation Messages are not a general campaign broadcast to phone-number lists.

## 2. Capture the customer’s choice

Explain the business and purpose before collecting explicit opt-in. Retain the consent evidence required by your workflow. Use the invitation phone-addressed path separately from ordinary conversation replies.

## 3. Use the approved template

Prepare the supported invitation fields and Apple-approved template. Validate the relevant business and device eligibility through the documented workflow. An ordinary reusable message template is not invitation approval.

## 4. Handle the response and conversation

Keep submission separate from acceptance or decline. Connect the customer’s response to the invitation and originating service request. When the customer accepts, continue through the conversation’s Apple identity with the case context available to the receiving team. A decline ends that invitation path. Leaving a conversation is a separate opt-out decision and must stop further invitations until fresh consent is obtained.

## 5. Prepare a permitted alternative

Configure a permitted alternative for a customer who cannot continue in Apple Messages. Match the channel to the service purpose and recorded preference, and carry the original case context into that path. Keep approval errors separate from device eligibility when deciding what should trigger fallback. Inspect an uncertain send before repeating it or starting another channel.

## Verify the customer-response branches

Use an approved test business and invitation template. Record an explicit opt-in for the defined service, then test acceptance and decline as separate cases. Inspect the invitation record, the opened conversation where applicable, and the original service request. The continuation should follow the customer’s recorded choice.

| Test case                                                       | Action                                                                  | Expected result                                                                |
| --------------------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| The customer accepts the invitation                             | Associate the resulting conversation with the promised service context. | The receiving team can continue the original request.                          |
| The customer declines the invitation                            | Record the response and retain the agreed alternative service route.    | The customer is not treated as having opened a Messages conversation.          |
| The customer cannot receive or does not continue the invitation | Use the permitted fallback defined for the service request.             | The request remains actionable without repeatedly sending the same invitation. |

## Troubleshooting

If an invitation fails, inspect business/template approval, address and supported-device conditions. Missing response data does not establish acceptance or decline. Inspect the existing request before repeating an invitation whose submission outcome is uncertain.

## Submission outcomes

A queued invitation is awaiting processing. A sent invitation was accepted by Apple’s gateway; it does not prove device delivery, reading or acceptance. A billing rejection means the send did not proceed, while a send failure can require investigation before retry. Use the [status explanation](/explained/apple-messages/does-sent-mean-delivered-or-read) when defining reports.

## Next steps

- [Explore the related Apple Messages capability](/products/apple-messages/invitations).
- [Find Apple Messages guides and answers](/products/apple-messages/resources).
- [Prepare your first complete conversation](/products/apple-messages/getting-started).

## Related resources

- [What is Apple Messages for Business?](/explained/apple-messages/what-is-apple-messages-for-business) (answer)
- [Apple Messages for Business](/products/apple-messages) (product)
- [Integrate an Apple Messages customer journey](/docs/guides/apple-messages/api) (docs)

[Get an implementation brief](/learn/workspace?topic=apple-messages)