Identity for airlines

Movmo Identity lets your site greet a traveler by name and pre-fill their details — with their explicit consent — even when they have no account with you and are not logged in. A first-time visitor who is a Movmo user can land on your homepage already recognized: personalized offers at search time, not after checkout.

The integration is deliberately small and almost entirely server-side: one embedded component on your site, one OAuth credential, and two backend endpoints. No PSS change, no new identity system, no Movmo SDK on your backend, and no handling of Movmo credentials in the browser.

Want to see it first?

There’s a 90-second demo video showing one traveler recognized across two airline sites. Ask your Movmo contact for the link, or book a walkthrough at movmo.io/book-a-demo.

The key principle: the traveler needs no account with you

The primary case is a traveler who is anonymous to you — new to your site, no account, not signed in. What authorizes recognition is never an airline login. It is a short-lived, single-use recognition token that Movmo’s embedded surface hands your page, which your backend redeems server-to-server with your client_secret. The token is the capability; a stolen one is useless without your secret.

If you run your own customer accounts, there is an optional convenience path for signed-in customers (Flow B below) — but it is exactly that: optional. An integration that never stores anything airline-side is complete.

How it works: two layers

Movmo separates identity (who is this?) from consent + data (may this airline see them?):

• Identity — in the browser. A Movmo-origin surface (the <MovmoRecognition /> component) recognizes a returning Movmo user from Movmo’s own first-party session. It never carries the traveler’s profile and never exposes a Movmo user ID. Your page only ever receives an opaque, short-lived token.
• Consent + data — server to server. Your backend presents that token (or a stored durable GUID) plus your client_secret to Movmo’s resolve API and receives exactly the claims the traveler consented to share with your airline. Every byte of personal data travels on this authenticated, auditable channel — never through the browser.

The durable identifier — the GUID — is a per-(traveler, airline) consent receipt and data handle. It is pairwise: your GUID for a traveler is unrelated to any other airline’s, so two airlines can never correlate a traveler by comparing identifiers. It is minted only when the traveler grants a named, revocable consent to share their Movmo profile with you, and it is never keyed to any account on your side.

What you build vs. what Movmo provides

You build	Required?	Purpose
Connect callback	required	Complete the one-time consent handshake (a thin page plus a backend code exchange)
Anonymous recognition	required	Exchange a short-lived token from the Movmo surface for consented claims — no airline account, nothing stored
Recognition on load	optional	For a signed-in customer whose GUID you chose to store, resolve directly without the browser round-trip
Unlink	optional	Let the traveler disconnect from within your own UI; clear a stored GUID
stored movmo_guid	optional	One opaque string, only if you keep customer accounts and want the direct path above

You hold one credential: a confidential OAuth client (client_id + client_secret), issued by Movmo per environment and kept server-side only. Movmo provides everything else — the recognition surface, the consent screens, the traveler’s management UI, and the resolve API.

The frontend piece is roughly 60 lines of your code; the two backend endpoints are thin wrappers around two Movmo API calls. The full build is documented, with copy-paste examples, in the integration guide.

The three flows at a glance

Flow	Traveler situation	What happens
A	First connection	Traveler approves a named consent on Movmo’s screen (OAuth 2.0 + PKCE); your backend exchanges the code and receives a movmo_guid
B	Returning customer, signed in to your site (optional)	Your backend resolves the GUID you stored in Flow A — no browser round-trip
C	Returning traveler, anonymous to you (the primary case)	The embedded surface recognizes the Movmo session and hands your page a short-lived token; your backend redeems it for the consented claims

Consent is checked on every resolve, and revocation is immediate: when a traveler withdraws your airline’s access from their Movmo account, your stored GUID stops resolving with a uniform 404. You honor it by deleting the GUID and treating them as not-connected — recognition simply stops.

Onboarding checklist

You can onboard today, and the build is deliberately small: most teams have recognition running against Movmo’s e2e environment in a day, loyalty linking on day two — see How long this takes. Production is a base-URL switch when you go live.

1. Contact Movmo. Book a call at movmo.io/book-a-demo or reach out through your existing Movmo contact. We’ll walk your team through the flows and agree scopes (typically profile.read and preferences.read).
2. Receive your credentials. Movmo pre-registers you as a named confidential client — a stable client_id and a client_secret delivered over a secure channel, per environment, with no TTL. Store the secret in your backend secret store; it must never reach a browser or a repo.
3. Register your redirect URIs. The consent flow only redirects to URIs pre-registered for your client. They must be https:// on a domain you control — see the requirements under How OAuth clients get provisioned. Tell Movmo when one changes; an unregistered URI fails the flow closed.
4. Install the component. npm install @movmo/connect-button (latest) — MovmoRecognition shipped in 0.2.0, and 0.3.0+ defaults to the e2e environment.
5. Build the two backend endpoints against https://e2e.api.movmo.io — the code exchange and the token resolve, per the integration guide.
6. Verify on e2e, then flip isProd on the component and switch your base URL when you go live.

Also give Movmo a security contact — ours is security@movmo.io — so either side can reach the other about credential compromise or a data incident — see Operations & compliance.

Traveler control, built in

Every grant lives in the traveler’s Movmo account, by name. The recognized surface on your page links to it (“Manage”), travelers can revoke any airline at any time, and re-connecting later mints a brand-new GUID — a retired handle is never resurrected. This is deliberate: the consent event is explicit, logged, and revocable, which is what makes the whole design defensible for your privacy review. Your side of those obligations is covered in Operations & compliance.

Loyalty single login (early access)

If you run a loyalty program, the identity layer extends so that one Movmo login signs your member in — the traveler links (or joins) your program with a single opt-in checkbox inside the same Movmo consent screen, and lands on your site signed in, with the login wall gone. Your loyalty stack stays the authority for accounts, balances, tiers, and redemption; Movmo only verifies which consenting traveler is on the page, and can hand you brand-new enrollments built from the traveler’s consented Movmo details.

The account-link API is available today, in early access: your backend calls POST /v1/identity/loyalty-link to associate a consenting traveler’s Movmo identity with their membership in your program, and from then on every resolve for that one Movmo login hands your member back to you recognized and verified — no second login, no separate loyalty lookup. Enrollment (building a brand-new membership from the traveler’s consented Movmo details) and ongoing profile sync remain scoping items — talk to us if that’s the piece your pilot needs.