API keys vs per-request payments
Use API keys when account and billing terms already exist. Use per-request payments for one bounded purchase without a billing account.
API keys fit buyers whose account, permissions, and billing terms already exist. Per-request payments fit buyers who need one bounded result without opening a seller billing account first.
The two models make the payment decision at different times. A key points to policy the seller stored earlier. A per-request payment gives the seller evidence for one price and one request. Neither one decides whether the caller may use the product, whether the input is safe, or whether the work should run twice.
The timing matters when an agent reaches an API in the middle of a job. An established customer's agent can reuse the terms attached to the customer's account. A new buyer can evaluate a price and pay for one result. The seller does not need to force both buyers through the same setup.
Where the seller decides how a request will be paid
The paths meet at the same product request.
API key path
Stored policy first
The seller creates the credential and billing policy before requests begin.
- Provision credential
- Resolve account policy
- Run the request
- Meter or invoice
Per-request path
Payment requirement first
The seller presents a price requirement and evaluates the buyer's payment payload at the request boundary.
- Present requirement
- Verify payment payload
- Run the request
- Record settlement
| Decision point | API key | Per-request payment |
|---|---|---|
| Payment decision begins | Before the request, during onboarding | At the request boundary |
| Evidence on the request | A credential mapped to seller-held client state | A payment payload matched to one offered requirement |
| Buyer fit | Repeat or contracted buyers with shared billing | Bounded purchases without a prior billing account |
| Separate controls | Product authorization, cost controls, and fulfillment | Caller identity, product authorization, and fulfillment |
What an API key proves
"API key" names a credential format. The format does not tell you who the holder is or how the seller will bill them. The current OpenAPI Specification defines an API-key security scheme by the key's name and whether it travels in a header, query parameter, or cookie. OpenAPI does not define the business entity behind the value.
The seller or platform decides what the key represents. Amazon API Gateway can associate a key with API stages, methods, quotas, and throttling through a usage plan. AWS says the key identifies the API client inside that plan. AWS warns against using API Gateway keys as the authentication or authorization control for an API. AWS also describes usage-plan quotas as best-effort limits, not hard spending caps.
Google Cloud draws another boundary. A standard API key associates a request with a project for billing and quota purposes. The key does not identify a principal for an IAM authorization decision. Google also offers authorization keys bound to service accounts. The same label can therefore refer to credentials with different security properties.
Treat a valid key as a lookup value for its assigned policy. The implementation decides whether the policy identifies a principal, grants product permissions, selects a plan, or only attributes usage.
An account-based key model decides terms before the request
Before accepting the first request, the seller creates a credential and links the credential to an account or application, available resources, and billing terms. Later requests can stay compact because the key retrieves the stored policy.
Account setup pays off for repeat buyers. One company may use several services under a contract, receive one monthly invoice, apply shared spending controls, and rely on an agreed support path. The key also gives the seller a stable reference for logs, usage reports, revocation, and migration.
The seller now owns the key lifecycle. Keys need secure delivery and storage, restrictions, monitoring, rotation, and revocation. Stripe's key guidance, for example, separates restricted keys from secret keys. Stripe treats rotation as a managed migration because old and replacement credentials may need to overlap.
Reusing an account saves work on later requests, but the buyer must create the account before the first request. The seller may also require accepted terms, a funding arrangement, and secure credential delivery. Account setup makes sense when future requests will reuse the policy. Account setup is harder to justify for a buyer who wants one result and may never return.
Per-request payment decides at the request boundary
In a per-request model, the server states the price and accepted payment requirements for the resource. The buyer selects one requirement and sends the matching payment payload. The seller verifies the payload before applying the seller's fulfillment policy.
The current x402 HTTP transport provides one implementation. A resource can respond with 402 Payment Required and a PAYMENT-REQUIRED header. The client then sends a PAYMENT-SIGNATURE header containing a PaymentPayload for one accepted requirement. A later PAYMENT-RESPONSE can report the settlement result.
A verified payload proves only that the payload matches the chosen payment requirement. Verification does not prove settlement or authorize the requested product action. The seller must still bind the evidence to the intended request, validate the input, prevent duplicate work, and record what happened if fulfillment fails.
The payload's request-level scope can suit a bounded resource. A buyer can assess an offer without joining the seller's invoicing system. The buyer still needs a compatible payment method and authority to use that method. If the buyer returns later, another identity mechanism may establish continuity. The payment evidence remains bound to the specific requirement.
The failure modes show what each model owns
With an API key, the first question is whether the credential is valid and which stored policy the credential retrieves. A request can fail because the key is missing, expired, revoked, outside its restrictions, or linked to an account without a usable billing arrangement. Rotation can also break a client that still sends the old key. These failures do not prove that the seller received payment for the request. The seller may meter the request now and invoice it later.
With per-request payment, failures sit closer to the purchase. The offer can expire. The payload can name the wrong amount, resource, recipient, network, or scheme. Verification or settlement can fail. A retry can repeat the work unless the seller ties the payment and request to an idempotent transaction record.
Both models still need product authorization and abuse controls. A valid key should not grant every action. A valid payment should not make unsafe input acceptable. Payment answers a commercial condition. Authorization decides whether the caller may perform the requested product action.
Support starts with different identifiers. For key-based billing, staff trace the key to a customer and then to usage and an invoice. For per-request payment, staff trace the offer and payment evidence to fulfillment and settlement. A hybrid can use the same request and transaction identifiers on both paths.
The buyer relationship determines the payment path
An API-key path fits buyers who expect an ongoing contract, shared billing, stable permissions, or repeated access. Account setup is justified when many requests reuse the same policy and finance wants consolidated charges.
Per-request payment fits a bounded resource when the seller can state the price before execution and the buyer should not need a billing account. This payment path works for intermittent demand and agents that discover the resource while completing a task.
A hybrid can accept a key or a payment for the same endpoint. Existing customers use their account terms. Other buyers receive a payment requirement for that purchase. Both routes can share product authorization, duplicate-request protection, execution, fulfillment, and transaction records. Billing operations may still differ.
The two payment paths need a clear boundary. A key bypasses a charge only when the account policy permits the bypass. Payment evidence does not create broader account permissions. Each transaction record needs the payment path, the evidence used, and the policy version.
A useful test starts with one bounded endpoint and two buyers. The established customer calls the endpoint repeatedly. The unknown buyer needs the endpoint once. The comparison covers when each buyer learns the price, which authority and payment evidence arrive with the request, and how the seller prevents duplicate work. The comparison also traces the outcome to billing or settlement. If both buyers need the same product behavior, the fulfillment path can stay shared while the payment decision remains separate.
How AI Agents Buy From Your Business places API keys and per-request payments inside discovery, quoting, authorization, execution, and settlement. How to Price an API for AI Agents shows how to define a bounded per-request offer that software can evaluate.
For the product context behind this series, visit recuut. Start with the path that matches the buyer in front of the resource. Add the second path when a real buyer relationship requires it.