Partner API Access Model

Partner API access is not a separate public self-serve pricing ladder. It is enabled through package entitlements, rollout state, key registry controls, and, for deeper integrations, contract-led onboarding.

Current access model

Access state	Typical use	How it is enabled
Starter approved access	Initial integrations and sandbox validation	Access request / onboarding approval
Private-beta pilot	Selected workflow automation and event delivery	Waitlist / pilot enablement
Enterprise contract	API-heavy integrations, governance, custom limits	Contract-led rollout

What determines access

• organisation package
• active API capability
• key registry state and scopes
• rollout state
• contract posture, if applicable

API keys

API keys prove that a caller is known and scoped. They do not, by themselves, enable public GA traffic, RFQ creation, quote automation, order automation, webhook delivery, or Master Data data-product access. Those capabilities require explicit contract and rollout enablement.

Master Data

Master Data is internal-only for external partners unless a private-beta contract and rollout explicitly enable a sanitized read projection. External GA is not enabled. Public Partner API access does not currently include externally enabled Master Data data-product endpoints, partner reads, entitlement scopes, quotas, SLAs, onboarding controls, or canonical write authority.

FAQ

Can I just upgrade from a self-serve billing page?

Not always. Partner API access is usually enabled through approval, pilot, or contract workflow rather than a generic checkout flow.

Is Partner quota enforced?

Not yet. Transactional reservation, accounting periods, and idempotent replay are launch blockers; do not build clients around a Partner quota 429 until the OpenAPI contract adds it.