Machine-readable purchase guide

Buy a pack. Keep the handoff legible.

A no-account protocol for software agents: discover a public pack, carry its stable identifier through hosted checkout, and accept a download only after payment is verified.

Browse the pack catalog
No account required
agent → buyer download

// the only public discovery surface

GET /buy.json

↓ choose a verified pack_id

POST checkout(pack_id)

↓ hosted payment redirect

POLL success(session_id)

verified → buyer-scoped download URL

01 / The protocol

Four checks between intent and bytes.

Keep the agent’s job small: discover, identify, pay, verify. The server owns pricing, entitlement, and fulfillment.

  1. 01

    Read the public catalog

    GET /buy.json returns only public pack metadata: a stable pack identifier, name, price, currency, purpose, and the next checkout action. It never contains seller or payment-private fields.

  2. 02

    Carry the pack identifier

    Select a verified pack ID from the catalog and send that ID to the checkout action. The server resolves the pack and price; the browser never chooses an amount, email address, return URL, or download URL.

  3. 03

    Follow hosted payment

    The checkout action creates a hosted payment session and returns its redirect URL. No account or sign-in is required for the intended flow, and card details stay with the payment provider.

  4. 04

    Poll for verified fulfillment

    After payment, poll the success verification path. Only a verified payment for the same pack may return buyer-scoped download URL(s). A pending, unpaid, expired, or unknown session returns no download.

02 / Public catalog

Read the menu before choosing the meal.

The planned /buy.json response is intentionally boring. Stable IDs make a pack unambiguous; public metadata lets an agent decide without receiving private seller data.

Contract status: this repository does not publish /buy.json yet. The sample below documents the intended public shape; it is not a live endpoint.

GET /buy.json · documented shape
{
  "packs": [
    {
      "id": "01",
      "name": "Agent Constitution",
      "price": 19,
      "currency": "EUR",
      "purpose": "Operating boundaries for an AI-run company"
    }
  ],
  "next": { "action": "checkout" }
}

Pack IDs must come from the live catalog. Do not guess an ID from a display name or send a browser-supplied price to checkout.

03 / Payment and fulfillment

Payment proves the handoff. It does not expose the seller.

Buyer output

After the server verifies the payment and pack relationship, the success response may contain only the buyer’s intended download URL(s) and public fulfillment status.

Seller side effect

Sale notifications are private seller-side work. They are never part of the buyer response and never reveal the owner’s email to an agent.

verified payment · documented response
{
  "status": "verified",
  "pack_id": "01",
  "download_urls": ["<buyer-scoped URL returned by the server>"]
}
Do not trust a redirect alone. A browser can arrive at a success URL without a settled payment. Poll the server’s verification result, match the returned pack identifier to the requested one, and stop on any non-verified status. This app does not yet expose the fulfillment route that would authorize the download URL.

Ready to inspect the packs?

Return to the public catalog for names, purposes, and current pack details.

See the catalog