Catalog and products
Use ATM product, price, discount, and discount-code records as portable commerce refs.
Compatible with the closed-beta ATM app APIs and versioned ATM event headers. Check atm-api-version on every webhook or XRPC receiver event.
Product and price separation
ATM follows a Product/Price model. Product records describe what is sold. Price records describe how that product is paid for. A product can point to a default price by strongRef.
money.atmosphere.product
Public identity for what is sold.
money.atmosphere.price
Amount, currency, one-time or recurring cadence, and custom amount rules.
money.atmosphere.discount
Public offer terms mirrored to processor coupon objects.
money.atmosphere.discountCode
Customer-facing redemption codes and restrictions.
Where records are written
Creator-owned catalog records are written to the creator's repo through their PDS. ATM indexes and resolves them during checkout, then mirrors the necessary processor objects privately.
Product images use the same ownership model. ATM-created images are uploaded as AT Protocol blobs to the creator's PDS and referenced from money.atmosphere.product. ATM serves a media-proxy/R2 cached URL for dashboards, checkout, and Stripe product images, but the blob ref remains the portable catalog source.
Creator-owned products are the canonical shared objects. If the creator updates the product in ATM, or an approved app writes the update back to ATM correctly, every app selling that product should resolve the updated title, description, image, price, variants, and archive state.
Completed purchases keep immutable payment/order snapshots, so old receipts and support views do not rewrite when a product changes later. The catalog strongRef identifies the current public product; historical purchase display should still use the checkout/payment snapshot where available.
App fulfillment links
Apps can register private fulfillment links for ATM catalog records. This lets ATM show "open in app" handoffs and send product update or archive events without putting app-private fulfillment state on protocol.
Apps such as Supper should use the ATM product strongRef as the shared product identity, then keep storefront-specific fields, purchase URLs, fulfillment URLs, presentation, app-local refs, shipping UI, downloads, custom-order workflow, and order state in app-owned sidecars or private app metadata. Those app-specific fields should not overwrite the canonical creator-owned product.
Shared finite inventory is the exception to app-local state. If multiple apps can sell the same physical product or scarce variant, ATM must own the private hold/consume/release lifecycle so apps cannot oversell.
App-owned products
App-owned products are different from creator-owned catalog records. A direct SaaS plan, premium app feature, or setup service sold by the app is direct app revenue and is not assumed to federate across other apps unless the app explicitly links it elsewhere.
Archive, do not delete
Normal creator-facing product removal should archive a product rather than deleting the public record. Archived products stay resolvable for old receipts, payments, attestations, and support workflows.