HomeSolutionsPartner Apps API

Partner Apps API

Partner Apps API

A partner apps API for teams building installable commerce integrations with hosted OAuth install, environment grants, and app-owned webhook endpoints.

Teams searching partner app APIs usually need more than OAuth. They need a full installable-app model with app registration, merchant installs, environment grants, token exchange, and webhook ownership.

Flint treats partner apps as first-class public resources instead of making ecosystem integrations live outside the main API.

The public surface covers app registration, installs, environment grants, OAuth exchange, and per-app webhook endpoints on one model.

Partner apps fit the same merchant and permission architecture as the rest of the Flint developer platform, which makes app installs easier to reason about later.

Use This Platform Shape When

Platform 1

You are building an installable product that many Flint merchants should be able to connect without support involvement.

Platform 2

Your integration needs app registration, install records, environment grants, and webhook ownership on one platform model.

Platform 3

You want the app ecosystem to live inside Flint's public API rather than being handled by custom contracts outside the developer platform.

Scenario 1

Register the app once

Create the partner app resource with callback URLs, permissions, and merchant-facing install identity before onboarding real users.

Scenario 2

Install across many merchants

Let each merchant create its own install and environment grants instead of sharing one credential across every customer account.

Scenario 3

Own app webhooks separately

Keep lifecycle events, signing secrets, and retry state on the partner app instead of mixing them into merchant-level endpoints.

Scenario 4

Rotate app credentials cleanly

Handle client-secret rotation, token exchange, and reinstall flows without rebuilding your own app-platform control plane.

Choose Something Narrower When

Use the OAuth page when the main design question is only the merchant approval and callback exchange step.
Use direct merchant-scoped API keys when this is a first-party integration with no installable app lifecycle.
Use the webhook infrastructure page when event delivery and operational debugging matter more than installable app architecture itself.

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.