OAuth for Commerce Integrations

Home SolutionsOAuth for Commerce Integrations

Hosted OAuth install flows for teams building commerce integrations that need merchant approval, callback validation, and install-token exchange.

Teams searching OAuth flows for commerce integrations usually need a merchant-facing install path that handles sign-in, merchant selection, permission review, callback safety, and token exchange without custom auth glue.

Flint exposes a hosted OAuth install flow with preview, authorize, and token-exchange routes instead of treating app installs as an internal dashboard-only action.

Merchant selection, permission review, and approval happen inside the Flint-hosted flow, so partner apps do not need to recreate account-linking UX themselves.

The same public partner-app model covers install lifecycle, token exchange, and per-app webhook configuration after the merchant approves access.

Open the Technical Surface

Quickstart

Start with the first request.

API Reference

Open the REST surface.

Orders First

See the core model.

Benchmark

Compare developer workflows.

Use This Platform Shape When

Platform 1

Third-party apps need merchant approval before they can read orders, issue refunds, or manage customer state.

Platform 2

You want Flint to own merchant sign-in, merchant selection, and permission review instead of recreating that UI in your app.

Platform 3

Your integration needs renewable install credentials and a clean token-exchange step rather than one long-lived shared secret.

Scenario 1

Merchant-approved app installs

Send the merchant through Flint-hosted install so approval, callback validation, and permission review happen on the same flow.

Scenario 2

Preview before redirect

Validate requested permissions and callback shape with the preview endpoint before you send the merchant into the hosted OAuth flow.

Scenario 3

Environment-aware token exchange

Exchange the returned install code for app credentials tied to the right environment without mixing live and test access paths.

Scenario 4

App-specific lifecycle handling

Pair OAuth install with partner-app webhooks so revoke, reinstall, and permission changes stay visible after the initial approval step.

Choose Something Narrower When

Use direct external API keys when the integration is first-party and does not need merchant-facing approval or revocable app installs.

Use the broader partner-app page when the real question is the full installable-app model, not just the hosted OAuth handoff.

Use merchant onboarding pages when the main problem is activating the merchant account itself rather than connecting an already active merchant to a partner app.

Implementation References

Reference the platform-level surfaces

Partner Apps API

Reference for partner app registration, hosted OAuth install, token exchange, and webhook configuration.

Partner App Installs Guide

End-to-end guide for hosted OAuth install, callback handling, and environment grants.

API Keys

Review the merchant-scoped API key model when your app still needs direct external-key workflows beside OAuth installs.

Explore the install, auth, and merchant platform model

These pages connect hosted app installs to direct auth, merchant onboarding, and the broader Flint platform architecture.

Partner Apps API

Use this when the full installable-app surface matters more than the hosted OAuth step alone.

Scoped API Keys for Payment Platforms

Useful when the real decision is between OAuth installs and direct merchant-scoped API key access.

Merchant Onboarding API with KYB

A good adjacent page when partner installs and merchant activation both need to fit one platform rollout.

Next Step

Wire the platform boundary first

Define auth, merchant scope, and install flow first, then let the narrower payment and checkout pages sit underneath it.