Identity operations & compliance

The integration guide covers the build; this page covers running it — and the small set of legal duties that come with receiving traveler data.

Security checklist

• client_secret lives only in your backend secret store — never in browser code, never in a repo.
• All token-exchange and resolve calls are server-to-server with client_secret_basic.
• The anonymous path (Flow C) is authorized by the recognition token + your client_secret — it needs no airline login, and the traveler may have no account with you. Just never redeem a token you didn’t receive from the Movmo surface for this session.
• The stored-GUID path (Flow B), if you use it, returns a specific customer’s personal data — gate it behind your own customer auth.
• On 404 from resolve, delete your stored GUID (revocation handling). No retries, no grace period.
• Recognition tokens are single-use and short-lived; never log them.
• Store only the opaque movmo_guid; you never need or receive a Movmo user ID.

What you do NOT build

• No identity provider, user store, or Movmo SDK on your backend.
• No handling of Movmo credentials in the browser.
• No PSS change.
• No cross-airline data plumbing — Movmo enforces the silo.

The integration is “one OAuth credential, two backend endpoints, one optional stored field.” Everything else is Movmo’s side of the line.

Operating the integration

Your day-2 responsibilities:

• Credential custody. Your client_id/client_secret is a confidential OAuth client credential: server-side secret store only. Movmo can re-issue a secret for your client_id on request — the current procedure re-provisions the registration, so coordinate a short maintenance window for the swap. Treat a suspected leak as an immediate-rotation event.
• Redirect URI registration. The consent flow only redirects to URIs pre-registered for your client. Register every environment’s callback with Movmo up front and tell us when one changes — an unregistered URI fails the flow closed.
• Egress allowlist. Your backend needs outbound HTTPS to the Movmo API host for /v1/oauth/token and /v1/identity/resolve. If you run an egress allowlist, add the Movmo API domain; there are no inbound calls from Movmo to your systems in the base integration.
• Incident contact. Movmo’s security and incident contact is security@movmo.io — use it for credential compromise, suspected token replay, or a traveler-data incident. Give Movmo your equivalent contact at onboarding so we can reach you the same way. Revocation of your client on Movmo’s side is the kill-switch: it invalidates resolve for every traveler at once.

Loyalty revocation

Loyalty adds a second revocation surface alongside the identity-claims one above (see the security checklist and the claim set) — know which trigger does what:

Trigger	Effect
Traveler revokes loyalty sharing (turns off loyalty.read for your client, from Connected apps)	Disclosure stops — loyalty drops out of your next resolve — but the underlying association is untouched. Re-granting restores it immediately, with no re-linking.
You call DELETE /v1/identity/loyalty-link	The association and the member data you supplied (member number, tier, points) are removed from Movmo entirely. A later link is a fresh POST, not a restore.
Traveler deletes their Movmo account	Cascades through everything tied to it, loyalty links included — same as any other consent and claim data.

Whose data is this, under GDPR?

The member data you push through loyalty-link — member number, tier, points — is data you disclose to Movmo, under a link the traveler initiated and can end at any time. It never originated with Movmo; Movmo only stores the association and, while loyalty.read stays granted, hands it back to you on resolve. Deleting the link — your DELETE, or the traveler’s account deletion — deletes that data with it. There’s no separate retention decision on Movmo’s side to track.

Your GDPR duties as a controller

When resolve hands you a traveler’s claims, you are a controller in your own right for that copy — Movmo is not acting as your processor, and the traveler’s consent to Movmo does not transfer your obligations. (The parties confirm their respective data-protection roles in the integration agreement.) Concretely:

• Your own transparency notice. Because you receive these claims from Movmo rather than directly from the traveler, this is the Article 14 duty (personal data obtained from another source), with its own timing rules. Your privacy notice must cover what you receive, why, and on what basis. Movmo’s consent screen names your airline as the recipient; your notice covers your side of the exchange.
• Purpose limitation. Use the claims for recognition and personalization of the traveler’s experience on your properties — the purpose the traveler consented to. Repurposing them (profiling, marketing lists, enrichment of other records) needs its own lawful basis and is outside this integration’s contract.
• No onward sharing. Claims are for your airline only. Passing them to other carriers, group companies not covered by the consent, or data partners breaks the carrier silo the whole design enforces.
• Deletion on unlink. A 404 on resolve is a revocation signal: delete the stored GUID and any cached claims. If you copied claims into your own records under your own lawful basis (for example, into a booking), that copy is governed by your retention rules — but the recognition profile must go.
• DPIA. For an EU rollout, expect to assess whether the sharing flow triggers a Data Protection Impact Assessment (Art. 35) — and if it does, to run your own, with Movmo supplying the architecture and consent-record documentation as inputs while you bring your processing context.

None of this is exotic — it is the same controller-to-controller pattern behind sign-in-with-X — but it is yours to operate, and legal review of your notice and retention rules is part of go-live.

Why the design reviews well

Three properties your privacy and security teams will ask about, answered by the architecture rather than by policy:

• The lawful basis is a recorded event. Nothing is shared until the traveler grants a named, per-airline consent on a Movmo-owned screen; the grant is timestamped, versioned, and revocable. There is no silent inference and no browser fingerprinting.
• Personal data never transits the browser. The browser only ever carries an opaque, short-lived token. Claims move on the authenticated server-to-server channel, and Movmo re-checks the traveler’s live consent on every resolve before any data is returned.
• Cross-airline correlation through Movmo’s identifiers is impossible by construction. Pairwise GUIDs plus uniform 404s mean your identifiers are meaningless to any other airline, and theirs to you.

Questions your reviewers can’t answer from this page? Book a session and bring them.