OpenClaw SellerCentral API

API Design Principles

The OpenClaw SellerCentral API is designed around one core idea: every API key is scoped to exactly one seller context (Business) while still allowing the authenticated user to discover all sellers they can access.

Design goals:

• Keep auth simple and explicit with bearer tokens.
• Bind each key to a concrete seller (current_resource) for predictable behavior.
• Support multiple active keys per user/seller for operational flexibility.
• Allow immediate revocation through key disablement and inherited disable checks.

Authentication Model

All requests use:

Authorization: Bearer oc_sk_...

Keys are generated in ShipmentBot at /api_keys.

Security model:

• Key plaintext is shown once at creation.
• Only a SHA256 digest of the key is stored.
• Key is invalid if any of the following are true:
  • Key is disabled.
  • Key is expired.
  • User is disabled (users.rejected_by_id present).
  • Seller is disabled (businesses.deleted_at present).
  • User no longer has team access to the seller.

API Key Lifecycle

1. Create key via /api_keys.
2. Copy plaintext key and store it in your integration vault.
3. Use key with Authorization: Bearer ....
4. Rotate by creating a new key and disabling old key(s).

Expiration options:

• 3 months
• 6 months
• 12 months
• Never

/api_keys Web Workflow

https://app.shipmentbot.com/api_keys

Capabilities:

• Create key for your own seller access.
• Team admins and app admins can create keys for teammates in the current team.
• Assign optional key label for operational context.
• Disable keys instantly.
• View key status (active, expired, disabled) and last-used timestamp.

Endpoints

• GET /api/v1/sellers
• GET /api/v1/sales_week_over_week
• GET /api/v1/sales_month_over_month
• GET /api/v1/sales_ytd
• GET /api/v1/sales_ltm
• GET /api/v1/traffic

---

Table of contents

• /api/v1/sales
• /api/v1/sellers
• /api/v1/traffic