Sharing your contact card
Offering your iMessage name and photo in a direct message.
name_photo.share offers your iMessage name and
photo to the other party in a direct message — the contact-card share Messages
prompts about when you start talking to someone new. Without it, the recipient
sees whatever their own address book has for your number, which for a new
contact is usually only the number itself.
It takes no arguments at all. The only thing you choose is who to offer it to.
This shares your own configured name and photo, not an arbitrary contact. To send someone a
contact as a tappable card, send a .vcf as an
attachment.
Sending it
The target is a direct-message conversation. Groups are not supported, and
neither is a bare phone number — you need a conversationId, which means the
conversation must already exist. See
Addressing a conversation.
The payload is empty, but the payload key itself is still required. Omitting
it entirely is rejected with 400 target_and_payload_required.
curl $MAPIER_BASE_URL/v1/commands/name_photo.share \
-H "Authorization: Bearer $MAPIER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"target": {
"kind": "conversation",
"conversationId": "a0000000-0000-4000-8000-000000000001"
},
"payload": {}
}'Like the other agent-turn commands, this honours Idempotency-Key, so a retry
adopts the original command rather than offering twice. Group commands do not
— see Idempotency for which is which.
Reading the outcome
The command settles succeeded whether iMessage actually showed the prompt or
declined to — usually because the card has already been shared with that person,
so there was nothing left to offer. Whether the prompt appears is iMessage's
decision, not something the command overrides, and the settlement event carries
only status and errorCode, so it does not report which of the two happened.
Treat a succeeded settlement as "the recipient has your card or already had
it". There is no signal anywhere in the API that distinguishes them, and nothing
to retry either way.
Some earlier API notes describe this command as also accepting a recipient target, which would
let you share a card with someone you have no conversation with yet. It does not: the wire schema
the connector validates against accepts a direct-message conversation only. A recipient target is
not caught at the boundary, so it returns 202 and settles failed rather than telling you
outright.
Sharing requires a Mac advertising command.name_photo_share.v1. A host
without it settles the command failed with unsupported_capability or
capability_not_negotiated rather than rejecting the request up front.