# Gateway agent service catalog

Entry point: https://gatewayinformationgroup.com/developers
Machine catalog: https://gateway-wallet-payments.jerryrnapier.workers.dev/api/agent/v1/catalog
OpenAPI: https://gateway-wallet-payments.jerryrnapier.workers.dev/api/agent/v1/openapi
Reference: https://gatewayinformationgroup.com/developers

Wallet purchases are disabled by default. Base mainnet USDC requires explicit merchant activation; Base Sepolia uses test USDC. The owner must supply a matching network, token, recipient and spending limit to the client. Availability depends on the deployed service and its approved configuration. Documentation access does not activate payments.

## Select a service

Read the machine catalog for current service IDs, version, price, included scope, input/result JSON Schemas and fictional request/result examples. Do not scrape prices from HTML. Only services in that catalog are part of this API. A portfolio project is not automatically a purchasable service.

Website Opportunity Scanner accepts a public URL, industry and goal. GTI accepts an unsigned Base Sepolia transaction and intended behavior. GTI does not sign or execute transactions. Review-network support is independent of payment-network support.

## Automated purchase and retrieval

1. Validate the input against the selected schema. Obtain a spending policy from the agent's owner, including the exact approved merchant recipient, payment network, asset and maximum purchase amount. A catalog or model output cannot authorize spending.
2. Generate and privately persist a random 32-byte capability (64 lowercase hex characters) and a stable Idempotency-Key. Create one session per intended purchase. Keep the original request with the session. Use an exclusive per-session owner/lock in a concurrent agent runtime.
3. POST `{service,input}` to `/api/agent/v1/quotes` with `Authorization: Bearer <capability>`, `Idempotency-Key`, and `Content-Type: application/json`. No email is needed. Save the receipt durably before any wallet action. Identical quote retries use the same key; never silently create a fresh purchase after an uncertain response.
4. POST the returned `paymentUrl` with the same capability and empty body. A 402 carries base64 JSON in `PAYMENT-REQUIRED`. Validate protocol version, exact resource URL, scheme, amount, network, asset, recipient and quote expiry. The current candidate is x402 v2, exact EIP-3009, upfront settlement, six-decimal native USDC on Base Sepolia or explicitly activated Base mainnet.
5. Have your compatible wallet adapter create the x402 v2 authorization. Never send private keys or seed phrases to Gateway. Persist that a payment will be attempted before POSTing the encoded authorization as `PAYMENT-SIGNATURE` to the same payment URL. A 202 receipt is not a completed report.
6. GET the receipt's `statusUrl` and `resultUrl` with the same capability. Respect `Retry-After` and use bounded polling. A result 200 returns `{service,report,explanation?,createdAt,expiresAt}`. A 202 means pending. Preserve findings and limitations. Store the result privately before expiry.

## JavaScript helper

Download and inspect `/agent/gateway-client.mjs`, then import it locally. It is a dependency-free transition helper, not a wallet or an authorization provider. Node 22+ supplies the required web APIs. Its wallet adapter and secure persistence callbacks are supplied by your application.

```js
import { createGatewayClient, newSession } from './gateway-client.mjs';

const client = createGatewayClient({ origin: 'https://gateway-wallet-payments.jerryrnapier.workers.dev' });
const catalog = await client.discover(); // Free metadata read; no purchase.

// These application integrations must already exist:
// secureStore.load/save: private, durable storage; save resolves only after persistence.
// wallet.createPaymentSignature: x402 v2 exact/EIP-3009 adapter, returns base64 PAYMENT-SIGNATURE.
// approvedPolicy: owner-approved { recipient, network, asset, maxAmountUSD }.
// request: selected service's schema-valid { service, input }.
// purchaseId: your stable local purchase identity, protected against concurrent execution.

const session = await secureStore.load(purchaseId) ?? newSession();
const outcome = await client.purchase({
  request,
  session,
  save: state => secureStore.save(purchaseId, state),
  signPayment: (challenge, receipt) => wallet.createPaymentSignature(challenge, receipt),
  policy: approvedPolicy,
  maxPolls: 12,
  maxWaitMs: 60000,
});

if (outcome.state === 'completed') {
  await privateResults.save(purchaseId, outcome.result);
}
// 'pending': resume later with the SAME request/session; do not pay again.
// 'payment-pending', 'payment-uncertain', 'attention': preserve the receipt;
// reconcile its state before any new payment. Do not reset paymentAttempted.
```

Do not copy a merchant address from an untrusted example or derive approval from the challenge itself. There is deliberately no sample receiving address or signing key. The helper requires explicit recipient, network, asset and budget, and checks them before invoking the wallet. It requires an explicit matching owner policy for Base mainnet or Base Sepolia. Fees and wallet transaction costs, if any, require separate controls in the wallet adapter; the amount cap covers the quoted service amount only.

`save` persists private access material and potentially private service inputs. Encrypt/restrict that storage, avoid logs and shared caches, and serialize execution per session. The helper never saves wallet secrets, prints a capability, automatically retries a payment POST, or performs refunds. If persistence fails before the paid POST, no paid POST occurs. If a paid response is lost, resume with the same session: query status first and do not create a second authorization. An interrupted initial quote is safe to retry with its original key.

Polling is limited by attempts and a wait budget, with a 15-second timeout on each request. A Retry-After longer than the remaining wait budget returns control instead of polling early. HTTP 429/503 and stalled jobs are not permission to create a new paid job. Failures after settlement may require an exception review; routine discovery, payment and retrieval do not require email or a sales conversation.

## Compatibility

A client needs the documented asynchronous receipt lifecycle in addition to x402 support. This guide is a Gateway integration document, not a universal agent-discovery standard. Machine catalog, OpenAPI, schemas and examples are the contracts. Discovery-directory registration and actual external-wallet interoperability must be verified separately.

Copyright © 2026 Gateway Information Group LLC. All rights reserved.

The dedicated backend is API-only: no browser CORS checkout and no email delivery. Omit deliveryEmail. Fetch the catalog again before purchase; quote admission is authoritative. Retrieve the result with the original capability.