ListBee Changelog

April 2026: Simplified architecture

ListBee’s API is now simpler and more powerful. Stores have been removed, listings have a proper lifecycle, and deliverables are mutable.

What changed

• Breaking: Store entity removed — accounts own listings directly. All /v1/stores/ endpoints are gone. Profile fields (display name, bio, avatar) now live on the account.
• Breaking: Listing management routes changed from /{slug} to /{listing_id}. Slugs are still used for public product page URLs.
• Breaking: Listing states changed from active/paused to draft/published/paused. New listings start as drafts and must be explicitly published.
• Changed: Deliverables are now mutable. Set, replace, or remove a listing’s deliverable via PUT /v1/listings/{id}/deliverable and DELETE /v1/listings/{id}/deliverable. Draft state only.
• Changed: File upload via POST /v1/files returns a token. Pass the token to the deliverable endpoint to attach files.
• Changed: Slugs are now derived from the listing name (human-readable). Changeable in draft, frozen after publish.
• Changed: Fulfillment mode is computed from deliverable presence — no longer set explicitly.
• Removed: Custom domains.
• Removed: Multi-store support. One account = one brand.
• New: Webhook delivery logs — GET /v1/webhooks/{id}/events to inspect delivery history.
• New: Webhook test endpoint — POST /v1/webhooks/{id}/test to verify your endpoint.
• New: Webhook retry — POST /v1/webhooks/{id}/events/{event_id}/retry to retry failed deliveries.
• New: Auto-disable for webhooks after 3 consecutive permanent failures.
• New: 29 supported currencies including zero-decimal currencies (JPY, KRW).

Migration

Store removal

Before:

$
POST /v1/stores              # create store
$
POST /v1/stores/{id}/stripe  # connect Stripe per store

After:

$
POST /v1/account/stripe-key         # connect Stripe on account
$
POST /v1/account/stripe/connect     # or use Connect onboarding

Listing routes

Before:

$
GET /v1/listings/{slug}
$
PUT /v1/listings/{slug}

After:

$
GET /v1/listings/{listing_id}
$
PUT /v1/listings/{listing_id}

Listing creation

Before:

$
POST /v1/listings  { name, price, deliverable: "https://..." }
$
# → active listing, immediately sellable

After:

$
POST /v1/listings                           { name, price }        # → draft
$
PUT  /v1/listings/{id}/deliverable          { type, value/token }  # → managed
$
POST /v1/listings/{id}/publish              # → published, sellable

Fulfillment architecture

ListBee now supports two fulfillment modes on every listing: managed (ListBee delivers digital content automatically) and external (your app handles delivery via webhooks). Sell physical goods, AI-generated content, custom services — anything that needs logic after payment.

What changed

• New: fulfillment field on listings — "managed" or "external". Defaults inferred from whether content is provided.
• New: checkout_schema on listings — collect custom fields from buyers at checkout (text, select, date, address). Max 10 fields.
• New: POST /v1/orders/{id}/fulfill — push generated content or mark external orders as fulfilled.
• New: POST /v1/orders/{id}/ship — record shipping carrier, tracking code, and seller note.
• New: Order status expanded — pending, paid, fulfilled, canceled, failed (was: pending, paid, expired).
• New: Order fields — checkout_data, shipping_address, fulfillment_status, carrier, tracking_code, seller_note, paid_at, fulfilled_at.
• New: Webhook events — order.fulfilled, order.shipped.
• New: configure_webhook readiness action — appears on external fulfillment listings without a webhook.
• Breaking: content_type renamed to deliverable_type, content_key to deliverable_key, content_value to deliverable_value, content_meta to deliverable_meta, has_content to has_deliverable.
• Breaking: order.completed webhook event removed — replaced by order.paid and order.fulfilled.
• Breaking: stripe_session_id removed from order responses.

Migration

Field renames

Before:

1
listing["content_type"]  # "file"
2
listing["has_content"]   # True

After:

1
listing["deliverable_type"]  # "file"
2
listing["has_deliverable"]   # True

Webhook events

Before:

1
if event["type"] == "order.completed":
2
    # handle order

After:

1
if event["type"] == "order.paid":
2
    # payment confirmed — start fulfillment
3
elif event["type"] == "order.fulfilled":
4
    # delivery complete

See the Fulfillment modes guide for the full overview, Selling physical products for address collection, and Dynamic fulfillment for AI-generated content delivery.

Google Analytics tracking

Sellers can now connect a GA4 Measurement ID to their account. ListBee injects gtag.js on product pages and thank-you pages, and fires a purchase event when an order completes. UTM parameters are configurable per listing with sensible defaults.

What changed

• New: ga_measurement_id field on AccountResponse — GA4 Measurement ID associated with the account
• New: PUT /v1/account now accepts ga_measurement_id — set or clear the Measurement ID (G-XXXXXXXXXX format, or null)
• New: utm_source, utm_medium, utm_campaign fields on CreateListingRequest, UpdateListingRequest, and ListingResponse — override per-listing UTM attribution (all optional, max 100 chars each)
• Behavior: When ga_measurement_id is set, gtag.js is injected on product pages and thank-you pages; a purchase event fires on the thank-you page with transaction_id, value, and currency
• Behavior: UTM defaults applied at render time — utm_source → listbee, utm_medium → product_page, utm_campaign → listing slug; null fields use defaults

See the Google Analytics tracking guide for setup steps and code examples.

Agent-native infrastructure

New endpoints

• POST /v1/account/signup + POST /v1/account/verify — agent-initiated account creation with email OTP
• GET/POST/DELETE /v1/api-keys — API key management
• PUT /v1/listings/{slug} — listing updates (content immutable)
• POST /v1/account/stripe-key — direct Stripe key input
• POST /v1/account/stripe/connect — Stripe Connect via API
• DELETE /v1/account/stripe — disconnect Stripe

Readiness evolution

• blockers → actions with kind (api/human) and next pointer
• Agents now know what to call and whether they can do it autonomously

Agent discovery

• /llms.txt endpoint for agent discovery
• Idempotency-Key header on all POST endpoints