pay.sh

What is pay.sh?

pay.sh is a pay-as-you-go way for AI agents and command-line tools to call paid APIs without creating an account, generating API keys, or managing subscriptions. Its purpose is to let agents purchase and use third-party services at the point of need—using one-line API call workflows.

The platform also includes a partners catalog: a directory where API providers publish services in a format agents can discover, inspect, and call with pay-per-use access. This is meant to close the “credentials designed for people” gap that can block autonomous agent workflows.

Key Features

• One-line payment handling for API calls: enables agents/CLI tools to trigger paid API access without separate sign-up, accounts, keys, or subscriptions.
• No accounts and pay-as-you-go access: reduces onboarding friction so autonomous workflows can proceed immediately.
• Partner services directory (catalog): provides a searchable listing of services that agents can discover and select.
• Endpoint inspection and service discovery: lets users view service details and endpoints before calling them.
• Pay-per-use pricing and usage model per service: services in the catalog show pricing/price status and are intended to be charged for the specific call.
• Works with agents and CLIs: shown via examples using tools like npx @solana/pay and curl workflows to access APIs.

How to Use pay.sh

1. Browse the services catalog to find the API provider and service you need for your agent task.
2. Inspect the listed endpoint(s) for the service, including the path used for calls.
3. Use the pay.sh flow to make the API request as part of your agent or command-line workflow—so payment happens alongside the call.

A typical starting point is to run a one-line command that demonstrates the “pay then call” approach (the site shows examples using npx and curl).

Use Cases

• Agent workflow that needs external data on demand: an agent can look up a weather forecast (example includes curl https://api.weather.ai/forecast) and pay for that specific call.
• Blockchain-aware agents calling RPC endpoints: agents can access pay-per-request JSON-RPC endpoints for blockchain networks (e.g., per-chain paths like solana-mainnet or ethereum-mainnet).
• On-chain and crypto research tasks: use a metered crypto/finance data service to retrieve metrics such as prices, DeFi TVL, yields, token balances, transactions, logs, gas, and Ethereum stats.
• AI agents that manage agent-specific email inboxes: create and operate dedicated email inboxes via a service that supports programmatic inbox creation and message retrieval.
• Document processing workflows: call OCR services to extract text and structured fields from documents using the specific OCR endpoints exposed in the catalog.

FAQ

• Do I need an account or API key to use pay.sh? The site states the model is “no sign-up, no account, no keys, and pay as you go.”

• How does pay.sh fit into an agent’s workflow? The catalog helps an agent discover services and endpoints, then the pay.sh call flow handles payment for the API call the agent needs.

• What kinds of services are available in the catalog? The page lists categories such as Compute, Crypto/Finance, Messaging, AI/ML, Data, and Media, with examples of endpoints and metering/price status.

• Is pay.sh only for AI agents, or can developers use it from the command line? The site presents examples for command-line usage (e.g., npx and curl), indicating it can be used by agents and CLI tools.

Alternatives

• Use paid APIs directly with traditional credentials (API keys + subscriptions): this targets developers who prefer direct integration but lacks the “no accounts/keys” pay-as-you-go agent workflow described for pay.sh.
• Build an internal agent billing layer: integrate your agent with provider APIs while routing payments through your own system; this can work for autonomous agents but requires you to handle credentials and billing orchestration.
• Use an agent tool-calling framework with separate metering/billing: some agent frameworks support tool calling, but payment handling typically requires additional setup compared with pay.sh’s “one line” pay-per-call approach.
• Consider using individual provider pay-per-use endpoints without a shared catalog: this avoids dependency on a single directory, but agents may need extra logic to discover pricing and endpoints across providers.