# Codex Web-to-JSON Purchase Contract

**Version:** 1.1  
**Product SKU:** `web-to-json-50`

## 1. Offer

Codex Web-to-JSON provides 50 prepaid, supported public pricing-page extractions for USD 10.00. This is a one-time purchase. There is no subscription, automatic renewal, automatic top-up, or credit expiry.

The server owns the SKU, price, currency, and capacity. The checkout request accepts a buyer email only and rejects caller-supplied commercial values.

## 2. Canonical raw documents

- Product document: `https://codeximmortal.com/web-to-json.md`
- OpenAPI document: `https://codeximmortal.com/web-to-json-openapi.json`
- Agent card: `https://codeximmortal.com/agent-card.json`
- Plain-language index: `https://codeximmortal.com/llms.txt`

## 3. Checkout and authorization

A buyer starts checkout with:

```text
POST https://codex-immortal-2c799423.base44.app/functions/web_to_json_checkout
Content-Type: application/json
```

```json
{ "email": "buyer@example.com" }
```

No external authentication is required to start checkout. The successful response returns a Stripe-hosted checkout URL. The buyer authorizes payment directly on Stripe. Neither an agent nor this service accepts card credentials or may self-authorize payment.

`x-base44-app-url` is a platform-managed server header used only to build Stripe return URLs. It is not an external caller requirement and does not permit caller-chosen return origins.

## 4. Verified payment and credit grant

A checkout redirect, browser callback, email address, order identifier, client reference, or delivery token does not grant credits. Credits are granted only after a signature-verified Stripe event confirms that the checkout session is paid and that its amount and currency match the persisted order. A checkout session can grant the purchased capacity once only. Concurrent or redelivered events are deduplicated before any capacity is added.

## 5. Access and security

The buyer receives a private delivery link after a verified credit grant. The link can issue or rotate a buyer-scoped API key; only the key hash is stored. Order identifiers, emails, client references, checkout URLs, and redirects are not credentials.

## 6. Consumption

One completed extraction that returns at least one plan record consumes one credit. A rejected URL, unsupported page, retrieval failure, worker failure, or extraction with no plan records consumes zero credits. Reusing the same idempotency key with the same normalized URL returns the original job and does not consume another credit.

## 7. Supported input and limits

The service accepts one public HTTPS pricing page per job. Private-network hosts, IP literals, embedded credentials, non-default HTTPS ports, internal domains, and attempts to bypass authentication are rejected. JavaScript-rendered pricing tables are not supported when the pricing content is unavailable in fetched HTML/text. Current limits include three redirects, 2,000,000 fetched bytes, 12 plan records, a 2,000-character URL, and one request per second per buyer account.

## 8. Records, delivery, and retention

Purchased extraction credits do not expire. Result retention is separate: the product documents a 30-day result-retention target, and automatic deletion has not yet been implemented or verified.

The verified-payment fulfillment flow attempts to send a private delivery link to the buyer email. No guaranteed product-specific activation or delivery timeline is currently published.

**Owner decision required:** approve any delivery service level before publishing it as a commitment.

## 9. Cancellations, refunds, and support

The purchase is a one-time prepaid credit pack. The current site policy states unused credits are not refundable and are not converted into a subscription. The refund window, refund conditions, and processing timeline remain owner decisions in the public refund policy.

For purchase or delivery support, use `https://codeximmortal.com/Contact`.

## 10. Authority boundary

An agent may evaluate the product and initiate the documented hosted-checkout request. A human authorizes hosted payment. Capacity originates only from verified payment processing. Agent execution occurs only through buyer-scoped credentials. Machine purchase remains false unless an authorized payment adapter is implemented and released.