A cinematic AI project foundry with luminous glass project cards, planning boards, prototype schematics, and blue-and-amber workshop lighting.
Fourthwall developer options 路 API and webhook map 路 2026-05-18

Fourthwall Developer Capability Map

A practical map of the APIs, webhooks, feeds, custom code surfaces, and automation paths available through Fourthwall's developer options.

Projects / Fourthwall research artifact

Fourthwall Developer Capability Map

Created 2026-05-18 路 11:00 EDT Source: Fourthwall developer docs and read-only API checks Store context: AugmentedThinker Boundary: no credential values exposed; write actions require Christopher approval
The developer surface is strong enough to make Fourthwall more than a manual storefront. It can become a product pipeline, a signal sensor, and eventually a controlled automation layer.

This page maps what Fourthwall's developer options appear to make possible for the AugmentedThinker store. The purpose is not to integrate everything at once. The purpose is to understand the available levers before we decide which ones belong in the first practical Fourthwall Product Loop.

The current developer surface has several distinct layers: the Platform API for shop management, the Storefront API for custom storefronts and carts, webhook subscriptions for real-time events, Custom Code/Liquid sections for storefront theme work, simple shop feeds for public product data, direct checkout links, membership APIs, and AI-facing support through MCP/Claude documentation.

Credentials testedThe shop-level Platform API credentials worked with Basic Auth against the current-shop endpoint.
Read-only snapshotThe API reported one collection, zero configured webhooks, 503 product templates, and existing archived/sold-out products.
Highest-value discoveryThe Platform API includes a Design Pipeline for product mockup previews and creating offers from design placement data.

Developer settings surface

The Fourthwall developer settings page appears to be the control center for Open API credentials, Storefront API tokens, webhook configuration, and Platform app/OAuth options. For our immediate store, the shop-level API key is the right starting point. OAuth is for a different problem: a public integration installed by multiple shops.

Platform API

The Platform API is the main management API. It lives under https://api.fourthwall.com/open-api/v1.0 and supports Basic Auth for our own shop. Fourthwall's docs describe it as the RESTful API for managing shop resources programmatically.

The Platform API Overview is also important because Fourthwall publishes full OpenAPI specifications in JSON and YAML. That means we can import the specs into tools like Postman, inspect endpoint schemas directly, or eventually generate a small typed client instead of hand-writing every request shape.

Products and availability

We can list products, fetch a specific product, check product inventory, and toggle product availability. The availability endpoint changes whether a product is visible and purchasable, but the docs warn that it does not manage inventory quantities.

Product templates

We can browse/search product templates and fetch product template details. The read-only check found 503 templates available. This matters because our design pipeline can choose concrete product blanks rather than treating "shirt" as a vague category.

Design Pipeline

This is the most important discovery for reducing product friction. The API has endpoints to create a design preview, create an offer from a design, and poll design pipeline status. The preview path can generate product mockup images from product and design placement data. The offer path can create a purchasable product offer after submission.

Media Library

The API can request a pre-signed upload URL, upload image bytes to that URL, and save uploaded images into the media library. This looks like the likely path for programmatic asset preparation once we have print-ready images.

Collections

We can list, create, update, set products for, and toggle availability for collections. The current read-only check found one collection: All Products. Collections could become useful if we create product lanes such as Field Notes, Companion Signals, or Workshop Marks.

Orders, donations, mailing list, payouts, reports

The API can read orders, donations, mailing list entries, payout status/transactions, and analytics reports. This is valuable for signal review, but it must be handled carefully because order/customer data can be sensitive.

Promotions, giveaway links, samples, streaming, thank-yous

These are useful later. Promotions could support campaigns, giveaway links could support controlled outreach, sample checkout could help product review, and thank-you endpoints could support customer/supporter workflows.

Storefront API

The Storefront API lives under https://storefront-api.fourthwall.com/v1. It is for custom shopping experiences built on top of Fourthwall's product catalog and checkout. Authentication uses a Storefront token from developer settings.

  • Fetch shop information.
  • List collections and fetch a collection by slug.
  • Fetch products inside a collection.
  • Fetch a product by slug.
  • Create carts, add/remove items, change quantities, and fetch carts.
  • Redirect customers to Fourthwall's hosted checkout.

This becomes important if we want a custom storefront, a Workshop page that displays products, a custom product gallery, or an alternate landing page that sends people into Fourthwall checkout.

Webhooks

Webhooks are the real-time signal layer. They let Fourthwall send JSON events to our endpoint when something happens in the shop. Webhooks can be configured through the dashboard or managed through the Platform API.

  • Order events: order placed, order updated, donation, gift purchase.
  • Product events: product created, product updated.
  • Collection events: collection updated.
  • Promotion events: promotion created, promotion updated, promotion status changed.
  • Cart events: cart abandoned at 1 hour, 24 hours, and 72 hours.
  • Newsletter events: newsletter subscribed.
  • Membership events: subscription purchased, changed, or expired.
  • Giveaway and thank-you events: draw started/ended, thank-you sent.
  • Platform events: platform app disconnected.

Webhook security matters. Fourthwall signs webhook requests with an X-Fourthwall-Hmac-SHA256 header. The receiver should compute an HMAC-SHA256 over the raw request body using the webhook secret, base64 encode it, and compare it with the header. Platform apps use a related X-Fourthwall-Hmac-Apps-SHA256 header.

  • Respond with HTTP 200 quickly. Fourthwall warns that responses longer than 2000ms may be marked failed.
  • Delivery is at-least-once, so duplicate events are possible. Store event IDs and process idempotently.
  • Ordering is not guaranteed between different topics for the same resource.
  • Delivery is not guaranteed in all cases, so periodic reconciliation with the API is still needed for critical data.

Current store webhook state: a read-only API check returned zero configured webhooks. That means we have a clean slate if we decide to add a webhook receiver later.

Custom Code and Liquid

Fourthwall supports Custom Code sections in the theme editor. These sections combine scoped CSS, HTML/Liquid markup, and section-scoped JavaScript. Liquid objects include collections, product, membership_tiers, and section.

This is the practical storefront-polish surface. Before building a separate custom storefront, we may be able to make the existing Fourthwall store feel better by adding custom sections: a better hero, a collection/story section, a featured product strip, or a Workshop-style explanation block.

Shop feeds and direct checkout links

Fourthwall also exposes simpler shop APIs that do not require the full Platform API:

  • Merchant Center RSS feed: {shop_url}/.well-known/merchant-center/rss.xml for public product information.
  • Collection JSON feed: {shop_url}/collections/{slug}.json for products in a collection.
  • Direct checkout links: /cart/checkout?products=variantId:quantity, with optional coupon, currency, cart origin, and marketing parameters.

These are useful for lightweight Workshop integrations. For example, a public Workshop artifact could display product concepts or link directly to checkout for a selected variant without building a complete Storefront API frontend.

Membership API

Fourthwall has membership surfaces for members, tiers, posts, post series, and tags. The docs expose both member/tier read operations and post creation/update operations. This is not our first priority, but it could matter later if the store becomes more than merchandise: supporter updates, member-only field notes, behind-the-scenes posts, or a small paid community layer.

AI and MCP support

Fourthwall documents AI-oriented access too: an MCP server, Claude app support, and LLM documentation support. The MCP server is described as giving AI assistants access to shop data such as products, orders, promotions, collections, analytics, and more.

This is strategically interesting because it overlaps directly with what OpenClaw is becoming. We should not rush into another integration layer before the basic API loop is clear, but it suggests Fourthwall already expects AI assistants to manage shop workflows.

What this enables for our pipeline

  1. Read the current store: list products, collections, inventory, and product states.
  2. Browse product templates: choose blanks that fit the design direction instead of guessing.
  3. Prepare design assets: generate/clean transparent artwork and validate print suitability.
  4. Preview designs: use the Design Pipeline preview endpoint to create mockup images when we are ready to test API-based production.
  5. Create offers: use the Design Pipeline offer endpoint only after Christopher approves product choice, design, title, description, and price assumptions.
  6. Organize collections: group products into intentional lanes.
  7. Expose products: use the Fourthwall store, Workshop pages, direct checkout links, or Bluesky posts.
  8. Capture signal: use webhooks for real-time events and API reconciliation for reliable review.

Approval boundaries

Because the Platform API credentials have full access for the shop, write actions need firm gates.

  • Safe without extra approval: read docs, inspect OpenAPI specs, list products/collections/templates/webhooks, and summarize non-sensitive store metadata.
  • Ask first: upload media, create previews that may consume resources, create products/offers, change availability, create collections, create promotions, configure webhooks, read customer/order details beyond aggregate counts, or touch payout data.
  • Never expose: API username/password, webhook secrets, customer personal data, order details, payout/account details, or raw private operational logs in public artifacts.

Recommended first implementation sequence

  1. Create a private read-only Fourthwall audit script that lists products, collections, product states, and template candidates without printing secrets.
  2. Create a product-template shortlist for the first design lane: classic tee, premium tee, hoodie, sticker, hat, or poster.
  3. Use manual storefront editing and Custom Code first if the store needs visual polish.
  4. Test the Design Pipeline preview endpoint with one approved non-public candidate.
  5. Only after the preview path is understood, consider creating an offer through the API.
  6. Later, add one webhook receiver for ORDER_PLACED, PRODUCT_UPDATED, and maybe abandoned-cart events, with signature verification and idempotent logging.

Open questions

  • Do we have a Storefront API token yet, or only the Platform API username/password?
  • Which product template should be the first standard blank for the Workshop design lane?
  • Can the Design Pipeline handle all the placement/mockup needs for shirts, or will some products still require dashboard/manual setup?
  • What analytics are available through reports, and are they enough for weekly product signal reviews?
  • Where should webhook events land: local file, hosted endpoint, Google Sheet, GitHub issue, database, or a small OpenClaw service?

Source links

Bottom line

Fourthwall's developer surface is strong enough for the product loop we want. The shortest path is not a full custom storefront. The shortest path is a controlled pipeline: read current products, choose a template, prepare a design, use API previews when ready, approve any write action, publish deliberately, and capture product signal through a mix of API reads and eventual webhooks.

My recommendation is to treat the Design Pipeline as the future automation spine, Custom Code as the near-term storefront-polish surface, and webhooks as the later signal-capture layer.