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. A returning Movmo traveler clicks “Checkout faster with Movmo” on your landing page and comes back greeted: personalized offers at search time, not after checkout. With a Movmo session and a standing consent that click needs no extra screen.

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

Start here

Three links cover the whole thing: what you get is this page; what you build is the integration guide (three small pieces, copy-paste examples); and the fastest way to build it is the prompt for your AI coding assistant. Credentials come from the onboarding checklist below.

Want to see it first?

There’s a 90-second demo video showing one traveler connecting to two airline sites in one click each. 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 the connection is never an airline login. It is the traveler’s own click on the chip and, on first use, one explicit consent on Movmo’s screen. Your backend then exchanges the resulting code server-to-server with your client_secret, and a stolen code is useless without your secret and the PKCE verifier. Nothing is asked of a traveler without that click.

If you run your own customer accounts, you can store the resulting GUID on the account (Flow B below) so later visits need no redirect — but that is optional. An integration that stores nothing airline-side is complete: the returning traveler just clicks the chip again.

How it works: two layers

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

• Identity — a redirect. The chip sends the traveler to Movmo’s own sign-in page, which checks Movmo’s first-party session. Nothing Movmo-origin is embedded in your page, and the browser only ever carries an authorization code — never the traveler’s profile and never a Movmo user ID.
• Consent + data — server to server. Your backend exchanges the code for a durable GUID, then presents it 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 chip	required	One ConnectMovmoButton (or one script tag) on your landing page; the SDK places it, no CSS or wrapper
Connect callback	required	A thin page plus a backend code exchange that returns a movmo_guid
Resolve	required	POST /v1/identity/resolve {guid} for the consented claims
Recognized state	optional	The chip recognizes a remembered device itself (opt-in per device): greeting, “Not you?”, “Manage”, “Forget this device”; onRecognized hands you a code to exchange; traveler is only a first-paint hint; clear your own link in onSignedOut
Stored GUID	optional	Keep the GUID on a customer account (or a sealed cookie) so later visits skip the redirect
Unlink	optional	Let the traveler disconnect from within your own UI; clear a stored GUID

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 sign-in and consent screens, the traveler’s management UI, and the resolve API.

The frontend 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 from Flow A or C — no browser round-trip
C	Returning traveler, one click (the primary case)	The chip click returns a code with no Movmo screen when a session and a standing consent exist; the same callback and exchange yield the movmo_guid to resolve

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 — the chip is offered again.

Onboarding checklist

You can onboard today, and the build is deliberately small — three pieces, listed under What you build. The one-click connect alone is a complete first scope; loyalty linking is one more backend call. 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 — for every host you will use. The consent flow only redirects to URIs pre-registered for your client, and the origins of those URIs (plus your airline domain) are also the origins Movmo allows for CORS and the Express Checkout return URL — see Where it can run. They must be https:// on a domain you control — see the requirements under How OAuth clients get provisioned. Give Movmo your production and staging hostnames up front (domains you control durably — never a shared tunnel or hosting subdomain); tell Movmo when one changes. An unregistered URI fails the flow closed.
4. Add the chip. npm install @movmo/connect-button (2.0.0 or later; it defaults to the e2e environment) — or one <script> tag if the site doesn’t run React.
5. Build the two backend endpoints against https://e2e.api.movmo.io — the code exchange and the GUID 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. Travelers can revoke any airline at any time from Connected apps, 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.

Signing out of Movmo is separate from revoking: the chip’s “Not you?” ends the Movmo session in that browser and calls your onSignedOut so you clear your own session; the GUID mapping stays until the traveler revokes in Connected apps. See Not you? and sign-out.

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.