Organization-Scoped Settings API

Home SolutionsOrganization-Scoped Settings API

An organization-scoped settings API for platforms that need shared defaults, policy records, and inherited controls across many merchants.

Teams searching organization-scoped settings APIs usually need shared defaults and policy enforcement across many merchants without copying the same configuration record into every account.

Flint exposes organization-scoped settings and policy rules directly on the public API instead of forcing platforms to fake inheritance in app code.

Settings policies are distinct from merchant selection, which makes shared defaults and enforcement easier to reason about in multi-merchant environments.

Teams can centralize fee rules, payment-method controls, and policy records at the organization layer without losing merchant-level runtime context.

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

Your platform manages many merchants and needs shared payment-method rules, fee defaults, or checkout controls from one higher-level policy surface.

Platform 2

You do not want to copy the same settings record into every merchant account just to keep platform defaults in sync.

Platform 3

You need org-level policy and merchant-level runtime activity to coexist without pretending they are the same thing.

Scenario 1

Shared checkout controls

Set default payment-method rules or platform checkout behavior once at the organization layer instead of recreating the same config merchant by merchant.

Scenario 2

Fee policy from the top down

Apply organization-level fee and payment-policy decisions while still letting day-to-day payment activity stay merchant-scoped.

Scenario 3

Multi-merchant governance

Keep policy inheritance explicit when one software platform owns many merchant accounts with common operational rules.

Scenario 4

Cleaner platform rollouts

Launch new merchants with shared defaults already in place instead of reconfiguring the same controls every time a new account comes online.

Choose Something Narrower When

Use merchant settings alone when each account is intentionally autonomous and shared defaults would add more confusion than leverage.

Use scoped API keys when the main architecture problem is auth and permission boundaries instead of shared configuration.

Use merchant onboarding when the current bottleneck is creating and activating new merchants rather than governing existing ones.

Implementation References

Reference the platform-level surfaces

Settings API

Inspect merchant and organization settings, including policy surfaces and checkout-related controls.

Organizations API

Review the organization resource model used for shared platform hierarchy and org-scoped records.

Payments API

Use this when org-level settings are ultimately shaping payment-method controls or platform fee behavior.

Explore policy, auth, and merchant rollout design

These pages connect organization-level controls to the auth model and merchant activation surfaces around them.

Scoped API Keys for Payment Platforms

Useful when shared policy and auth boundaries both need to be designed together across multi-merchant systems.

Merchant Onboarding API with KYB

Go here when multi-merchant rollout also includes activation and onboarding flows for newly created accounts.

Payments API for Vertical SaaS

A broader page for teams building software platforms where org-level defaults sit above merchant-specific runtime activity.

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.