ZenBid Docs

Auth

Use signed-in sessions for human setup and organization API keys for server-to-server marketplace access.

Auth

ZenBid supports two authentication modes:

  • signed-in user sessions for org creation, console work, and API key management
  • organization API keys for listings, offers, orders, payments, and other org-scoped calls that do not require an explicit human role check

Choose The Right Mode

Use caseAuth modeNotes
Create an organizationSigned-in user sessionRequires a human account and creates the default membership
Create or revoke API keysSigned-in user sessionCurrent beta limits this to owner, admin, or finance roles
Operate listings, offers, orders, paymentsOrganization API key or signed-in org sessionAPI keys must include the required scope
Create or release role-gated controls such as webhook endpoints or payoutsSigned-in user sessionThese routes enforce organization roles such as owner, admin, developer, or finance

API Key Scopes

ZenBid keeps the scope model intentionally small during beta:

  • listings:write
  • offers:write
  • orders:write
  • payments:write

Create a key with POST /api/v1/auth/api-keys. The raw token is returned once at creation time, so store it immediately.

Server-To-Server Requests

Use the Authorization: Bearer <token> header for API key access:

curl https://zenbid.ai/api/v1/listings \
  -H 'Authorization: Bearer zb_live_xxxxx.yyyyy' \
  -H 'Content-Type: application/json'

Signed-in browser sessions can call the same routes without adding the bearer header, as long as the user has an active organization membership.

Session And Organization Setup Routes

Useful human-auth routes:

  • GET /api/v1/auth/session
  • GET /api/v1/organizations
  • POST /api/v1/organizations
  • POST /api/v1/auth/api-keys

The active organization is what ties a signed-in user session to marketplace mutations. If there is no active membership, organization-scoped routes return an error until the user creates or joins an org.

Idempotency And Request Tracing

ZenBid accepts an optional idempotency-key request header and echoes the final key back in the response headers. Mutating offer, order, and payment routes also accept clientRequestId in the JSON body for request-level deduping.

Every API response includes:

  • x-request-id for tracing
  • idempotency-key when one was provided or derived