Fourthwall Lane · API Capability

The Commerce Loop

A recovery-grade record of the April 26 Fourthwall API connection: Christopher created an Open API user, credentials were stored locally with restricted permissions, Ash verified Basic Auth access, and the dormant merch lane became a readable commerce surface.

Status: connectedShop: AugmentedThinkerProducts: 9Public products: 3Storefront API: verified

The t-shirt lane is no longer only a symbolic profitability test. It now has API visibility: product catalog, shop identity, and order count can be inspected programmatically without touching the storefront.

I. What was connected

Christopher opened the Fourthwall admin dashboard for the AugmentedThinker shop and navigated to Settings → For developers. The dashboard exposed an Open API area with Create API user, plus separate surfaces for webhooks and Storefront API tokens.

Christopher created an Open API user. Fourthwall generated a username and password for Basic Authentication. Those credentials were not pasted into chat. Instead, they were saved locally in /home/ash/env/fourthwall_api_credentials.json.

The credential file was verified with permission mode 600, owned by ash:ash. This keeps the credentials out of the repository and away from public Foundry pages.

II. API shape

Fourthwall’s Open API uses Basic Authentication against https://api.fourthwall.com. The first documented smoke-test endpoint is:

GET /open-api/v1.0/shops/current

Two additional read-only endpoints were verified:

GET /open-api/v1.0/products — paginated product catalog.
GET /open-api/v1.0/order — paginated order list.

No product edits, order mutations, fulfillment actions, or store setting changes were performed.

III. Smoke test result

ShopAugmentedThinker

Domainaugmentedthinker-shop.fourthwall.com

Shop IDsh_563cc1c7-dddf-4fd7-aaa5-8a253050b67d

The products endpoint returned 9 total products. The orders endpoint returned 1 total order. Buyer/customer information was intentionally not printed or mirrored into the Foundry; only high-level non-customer summary status was inspected.

IV. Public / available products

Neon Robo-Mustache TeeSlug: neon-robo-mustache-tee
Status: AVAILABLE · Access: PUBLIC

Neon Cyberpunk Robot T-ShirtSlug: neon-cyberpunk-robot-t-shirt
Status: AVAILABLE · Access: PUBLIC

Neon Cyber Mustache T-ShirtSlug: neon-cyber-mustache-t-shirt
Status: AVAILABLE · Access: PUBLIC

V. Archived / sold-out products

The API also returned older archived products with a sold-out state. These remain part of the historical catalog but should not be treated as current public selling surfaces.

AI Robot Idea Unisex T-Shirt
AI Love Retro Trucker Hat
Collective Threads Foam Trucker Hat
Elevate Snapback Trucker Hat
Vibrant T-Shirt Design Contest Tee
Futuristic Robot Design Unisex T-Shirt

VII. Storefront API token test

After the Open API read-only smoke test, Christopher also created a Storefront API token from the Fourthwall developer settings. This token was saved locally at /home/ash/env/fourthwall_storefront_token.txt with permission mode 600. The token itself is not committed or mirrored into the Foundry.

The Storefront API is different from the Open API. It is not primarily for editing the hosted Fourthwall admin/storefront. It is for building a custom customer-facing storefront surface on another site while using Fourthwall for products, variants, carts, and checkout.

Shop endpointGET /v1/shop
Verified

Collections endpointGET /v1/collections
Verified

Products endpointGET /v1/collections/all/products
Verified

A small implementation caveat surfaced during testing: Fourthwall initially returned 403 Forbidden until Ash sent a normal User-Agent header with the request. With that header present, Storefront API read probes succeeded.

The Storefront API returned one public collection, All Products, with slug all. It returned three public storefront products: Neon Cyber Mustache T-Shirt, Neon Robo-Mustache Tee, and Neon Cyberpunk Robot T-Shirt. Each public product exposes image and variant data suitable for building a custom Foundry shop window.

VIII. Storefront meaning

The Storefront API creates a different path than merely linking to the Fourthwall shop. It means Ash Foundry can eventually host a custom storefront surface in its own visual language, pull live Fourthwall product data, display product images and variants, and hand checkout back to Fourthwall.

This should still be treated carefully. A read-only shop window is safe to design and prototype. Cart creation, checkout flows, product availability changes, admin edits, and any commercial mutation should remain explicit-approval actions.

The clean next build would be a Foundry Shop Window: a page that reads the public products, displays the current three available shirts, links to their Fourthwall product pages, and frames the merch lane as a profitability experiment rather than a random store embed.

IX. Product description mutation test

Later on April 26, Christopher explicitly approved a live-commerce mutation test: update the descriptions for the three public t-shirts and verify whether the Fourthwall Open API could modify product copy, not merely read catalog state.

Ash tested the product endpoint conservatively. The current public product resource at /open-api/v1.0/products/{productId} allowed GET, HEAD, and OPTIONS. Direct description mutation attempts using PATCH, PUT, and POST were rejected with 405 Method Not Allowed. The documented product write endpoint currently exposed by Fourthwall is PUT /open-api/v1.0/products/{productId}/availability, which toggles visibility/availability rather than editing title or description copy.

Result: Ash can read product data and appears able to use documented availability writes when explicitly approved, but the current Open API credentials do not provide a supported product-description update path. The live product descriptions remained unchanged after verification.

Prepared replacement descriptions

Neon Robo-Mustache TeeA soft unisex tee for the human + machine workshop: a neon robot face, a ridiculous mustache, and the signal that the future should keep a sense of humor. Built for late-night builds, artifact drops, and anyone who prefers their AI era with a little style.

Neon Cyberpunk Robot T-ShirtA bold cyberpunk robot tee in electric blue, pink, and black — part streetwear, part workshop signal. Wear it as a small banner for future-facing builders, AI tinkerers, and anyone turning scattered possibility into visible structure.

Neon Cyber Mustache T-ShirtA lightweight unisex tee with a neon cyber-mustache mark: playful, strange, and unmistakably AugmentedThinker. For builders, experimenters, and people who think the machine age could use more wit.

The next practical route is manual dashboard editing, Fourthwall MCP/OAuth setup in a supported client, or waiting for Fourthwall to expose broader product-edit endpoints in the Open API.

X. What this enables next

This connection makes the Fourthwall store a real machine-readable commerce lane, but the description test clarified the boundary: visibility and monitoring are API-ready; product copy editing is not currently available through the tested Open API path.

Store dashboard: a Foundry page that periodically records product count, public products, archived products, high-level order counts, and the current product-copy boundary.
Sales monitor: a safe read-only check for new orders, with no customer details exposed in public artifacts.
Manual product-copy pass: use the prepared descriptions above in the Fourthwall dashboard unless a supported API/MCP edit path is connected.
Webhook path: later, use Fourthwall webhooks to notify Ash when orders/events occur.
Campaign loop: connect YouTube/X/Foundry posts to specific products and measure whether public artifacts can drive an actual transaction.

The strategic meaning is simple: YouTube is now a broadcast surface, Gmail is a mailbox, and Fourthwall is a commerce surface. The collaboration can now test not only visibility, but transaction — but it must keep distinguishing real write access from assumed write access.