Selling

Bidder Registration & Approval

Collect bidder details, vet participants, and control who is allowed to bid — either manually or against rules you define.

Some sales require bidders to register and be approved before they can take part. Registration lets you collect bidder details, vet participants, and control who is allowed to bid — either manually or against a set of rules you define.

Registration is optional. If a sale has no registration requirement, any holder of a valid bidder token can bid.

When to use registration

You need to approve bidders before they participate (e.g. high-value sales)
You assign paddle numbers for live or saleroom auctions
You take phone bids and need to capture preferred numbers
You want to enforce conditions (policies) before a bidder is allowed in

Registration types

Type	Description
`ONLINE`	Standard online bidder registration
`PHONE`	Phone bidder — captures preferred and alternative phone numbers
`PADDLE`	Paddle registration for saleroom / live bidding
`AGGREGATOR`	Registration originating from a third-party aggregator

Registration status

Every registration moves through a simple lifecycle:

Status	Meaning
`PENDING`	Awaiting approval
`ACCEPTED`	Approved — the bidder may participate
`REJECTED`	Declined — includes an optional reason

Lifecycle overview

Text

Bidder registers ──▶ PENDING ──▶ (review) ──▶ ACCEPTED
                                          └──▶ REJECTED

A registration is created for a bidder against a sale (createSaleRegistration)
Any attached policies are evaluated and surfaced as policyResults
You accept or reject the registration
Approved bidders can be issued (or continue to use) a bidder token to bid

Registration policies

A policy is a named, reusable condition that must pass for a registration to be eligible. Each policy has:

A code — a stable identifier you can reference in your own UI
A human-readable description — safe to display to bidders
A rule — the condition that is evaluated
An isDefault flag — when set, the policy is applied automatically to every new sale on the account

Policies are evaluated per registration and returned as policyResults, so you can show a bidder exactly which requirements they have met and which are outstanding.

GraphQL

query SaleRegistrations {
  saleRegistrations(accountId: "ACCOUNT_ID", first: 20) {
    edges {
      node {
        id
        userId
        type
        status
        identifier
        policyResults {
          code
          passed
          description
        }
      }
    }
  }
}

Common operations (Management API)

Operation	Purpose
`createSaleRegistration`	Register a bidder for a sale
`acceptSaleRegistration`	Approve a pending registration
`rejectSaleRegistration`	Decline a registration (with a reason)
`deleteSaleRegistration`	Remove a registration
`createSaleItemRegistration`	Register a bidder for a specific item
`createSaleRegistrationPolicy` / `updateSaleRegistrationPolicy`	Define reusable approval conditions
`attachSaleRegistrationPolicies` / `detachSaleRegistrationPolicies`	Apply or remove policies on a sale

Example: approve a registration

GraphQL

mutation AcceptRegistration {
  acceptSaleRegistration(accountId: "ACCOUNT_ID", input: {
    registrationId: "REGISTRATION_ID"
  }) {
    id
    status
  }
}

Bidder-facing view (Client API)

Bidders can see their own registration state — including outstanding policy requirements — through the Client API, so your storefront can guide them through approval before bidding opens.

Staying in sync

Registration changes emit webhook events, so your back office can react without polling:

SaleRegistrationCreated
SaleRegistrationUpdated
SaleRegistrationDeleted
SaleItemRegistrationCreated
SaleItemRegistrationDeleted

See Webhooks for payload details and Managing Webhooks to subscribe.