Profile

The profile domain is the user record: name, email, phone, date of birth, known traveler number, plus locale and travel preferences. Email and phone changes go through a three-step verified flow because both are authentication factors.

Common patterns

• Prefer GET /v1/users/me over GET /v1/users/{userid}. The me endpoint resolves the traveler from the token’s session, so no UUID in the URL.
• PUT /v1/users/{userid} does not accept email or phone — those fields are ignored if sent. Use the contact-change flow. The update is a full replacement of the profile fields (an omitted field is cleared), and date_of_birth is an RFC3339 date-time such as 1988-07-12T00:00:00Z.
• Contact change is three steps: initiate (sends a code) → verify-identity (returns a new flow_id in the response body) → confirm. All scoped to me.
• Locale and travel preferences upsert via PUT. No POST. Read returns defaults (en / US / USD) when unset.

REST endpoints

Operation	Path
getCurrentUser	GET /v1/users/me
getUser	GET /v1/users/{userid}
updateUser	PUT /v1/users/{userid}
initiateContactChange	POST /v1/users/me/contact/initiate
verifyContactChangeIdentity	POST /v1/users/me/contact/verify-identity
confirmContactChange	POST /v1/users/me/contact/confirm
getLocalePreferences	GET /v1/users/{userid}/locale-preferences
upsertLocalePreferences	PUT /v1/users/{userid}/locale-preferences
getTravelPreferences	GET /v1/users/{userid}/travel-preferences
upsertTravelPreferences	PUT /v1/users/{userid}/travel-preferences

Full schemas in the OpenAPI spec under tags: [Profile].

MCP tools

Model Context Protocol (MCP) wrappers for this domain:

Tool	Maps to
get_user_profile	GET /v1/users/me
get_travel_preferences	GET /v1/users/{userid}/travel-preferences
get_locale_preferences	GET /v1/users/{userid}/locale-preferences

There is no MCP tool for the contact-change flow or for PUT /v1/users/{userid}. Profile writes happen via REST or the accounts UI today.

Watch out for

• getCurrentUser returns null for first_name and last_name until profile setup completes. Treat them as optional. phone_number is captured at signup and is always non-null (sometimes a placeholder for test accounts).
• DELETE /v1/users/{userid} is not in the partner surface — see under review.