Skip to main content
GET
Get a party's partner-terms consent state
Requires scope: manage:parties — see Required scopes. Returns one status and, while acceptance is outstanding, one consentUrl — covering every partner the party is onboarding to. You never deal with partners individually.
REQUIRED always comes with a consentUrl. That pairing is guaranteed — if the platform reports terms outstanding without a link, you get a retryable 503 instead of a REQUIRED you can’t act on.
Each call returns the current state and link, so an expiring or re-issued link is never stale. If you’d rather poll the plain party read, partnerTermsStatus on Get party details carries the same value.
ACCEPTED is not the end. It is evaluated against the terms active now, so enabling a new partner — or a partner publishing a new terms version — supersedes what was accepted and moves the party back to REQUIRED. Re-read it; don’t record it as a done milestone.

Errors

A 503 here never means “nothing outstanding”. The endpoint fails closed rather than guessing, so treating it as NOT_REQUIRED would skip the gate. See Partner-terms consent.

Authorizations

Headers

x-tenant-id
string<uuid>

Which tenant the request is scoped to, among those your token grants. Omit it when the token grants exactly one tenant; it is required when the token grants more than one. A supplied value must exactly match a tenant the token grants.

Absent when required, blank, malformed, or naming a tenant the token does not grant — each gets the same generic 403 forbidden, which reveals neither whether a tenant exists nor which ones you may use. Send the header once: a repeated header is rejected the same way.

Example:

"3fa85f64-5717-4562-b3fc-2c963f66afa6"

Path Parameters

partyId
string<uuid>
required

Unique party identifier

Response

The party's consent state

success
boolean

Indicates whether the request was successful

result
object

A party's partner-terms consent state, current as of the call.