Merchant Selection and Delegated Auth API

A merchant-selection and delegated-auth API for installable apps that need Flint-hosted merchant approval, permission review, and renewable environment grants.

Teams searching merchant-selection or delegated-auth APIs usually need a safer way for third-party apps to gain merchant-approved access without sharing one direct API key across many customer accounts.

Flint's hosted install flow already handles sign-in, merchant selection, permission review, and approval instead of making each partner app recreate that control plane.

The result is an install token and environment grants tied to the selected merchant rather than a broad shared credential reused across accounts.

That model fits Flint's broader merchant-scoped auth rules, so delegated access stays explicit instead of hiding behind ad hoc impersonation.

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

A third-party app should gain access only after a Flint merchant explicitly chooses the account and approves the requested permissions.

Platform 2

You do not want one merchant-scoped API key copied across every customer workspace in your product.

Platform 3

The integration needs renewable grants and a hosted install approval flow rather than ad hoc impersonation patterns.

Scenario 1

Merchant-picked install target

Let Flint handle merchant sign-in and account selection so the app receives delegated access for the right tenant from the start.

Scenario 2

Permission review before access

Show the requested permission set during install instead of burying access scope in out-of-band support docs or settings toggles.

Scenario 3

Environment-aware grants

Issue install access with mode-aware environment grants so test and live merchant connectivity stay explicit after approval.

Scenario 4

Revocable app access

Treat delegated auth as an install lifecycle with inspectable grants and revocation instead of a static secret that keeps spreading.

Choose Something Narrower When

Use scoped API keys when the integration is first-party and no merchant-facing approval screen is needed.

Use the OAuth page when the current step is only the hosted install handoff and callback contract.

Use partner apps when delegated auth is one part of a broader app platform with webhook and revocation lifecycle.

Implementation References

Reference the platform-level surfaces

Partner Apps API

Review the hosted authorize, preview, token exchange, and install inspection routes.

Partner App Installs Guide

See Flint-hosted merchant selection, permission review, callback handling, and install token exchange end to end.

Merchants API

Understand the direct merchant-scoped model that delegated installs sit beside rather than replacing.

Explore hosted OAuth, install records, and direct merchant auth

These pages help narrow whether the right next step is delegated app access, partner-app lifecycle, or direct merchant-bound credentials.

OAuth for Commerce Integrations

Use this when the core question is the hosted OAuth handoff rather than the broader delegated-access model.

Partner Apps API

Go here when delegated auth also needs app registration, installs, webhooks, and revocation lifecycle.

Scoped API Keys for Payment Platforms

Compare delegated installs with direct merchant-bound machine keys when deciding how integrations should authenticate.

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.