procurement.txt

Merchant Guide

This guide is for businesses that want to publish a procurement.txt file to make their purchasing process discoverable by AI agents and automated buying systems.

Why Publish procurement.txt?

AI purchasing agents are increasingly being used by businesses to automate procurement workflows. Without a standard signal, these agents must resort to scraping your website, guessing your contact methods, or building per-vendor integrations.

By publishing a procurement.txt file, you:

  • Save time — agents can instantly discover your ordering and pricing information without a sales call.
  • Control the narrative — you declare exactly what capabilities you offer and how to engage with you.
  • Future-proof your business — as AI-assisted purchasing grows, early adopters benefit from increased discoverability.
  • It's free and takes minutes — no registration, no SDK, no ongoing maintenance beyond keeping the file current.

Quick Start

Step 1: Create the file

Create a plain-text file named procurement.txt. The minimum valid file is:

Version: 1
Contact: mailto:sales@yourbusiness.example

Step 2: Add optional fields

Add fields based on what you want to communicate:

Version: 1
Contact: mailto:sales@yourbusiness.example
Pricing: public
Ordering: website https://yourbusiness.example/shop
Negotiation: no

Step 3: Upload to your web root

Upload the file so it is accessible at:

https://yourbusiness.example/procurement.txt

Step 4: Verify

Use the validator on the homepage to check your file is accessible and valid.

Creating the File

Required fields

Every valid procurement.txt must include:

  1. Version: 1 — always on the first or an early line.
  2. At least one Contact: — a mailto:, https:, or tel: URI.

Add these to improve your Agent Readiness score:

  • Pricing: — how agents can get pricing (public, on-request, api, catalog).
  • Ordering: — how agents can place orders (website, email, api, phone).

Optional fields

Add these as relevant to your business:

  • Commerce-Protocol: — agentic commerce protocol(s) you support (e.g., ucp, acp), with endpoint URI. Repeatable.
  • Interaction-Model: — how much human involvement your procurement flow requires (automated, approval-required, human-led, hybrid).
  • Negotiation: — whether you negotiate (yes, no, bulk-only).
  • Service-Region: — geographic regions you serve (ISO 3166-1 alpha-2 codes, or global).
  • Min-Order: — minimum order value (e.g., 500 USD) or none.
  • Payment-Terms: — accepted payment methods (e.g., net-30, purchase-order, credit-card).
  • Auth: — authentication required for your APIs (e.g., api-key, oauth2).
  • Escalation: — where to hand off an active transaction to a human.
  • Catalog: — a URI to your product catalog.
  • Rate-Limit: — advisory rate limit for automated requests.
  • Preferred-Languages: — languages you conduct procurement in.
  • Expires: — when agents should re-fetch this file.
  • Canonical-Hash: — SHA-256 integrity hash for tamper detection.
  • Capability fields (Quote:, Invoice:, Tracking:, Returns:, Subscription:, Rfq:) — declare how each supported capability is accessed.

Field Reference Examples

Contact

Use mailto: for email, https: for a contact form or chat, tel: for phone:

Contact: mailto:procurement@example.com
Contact: https://example.com/contact-sales
Contact: tel:+1-800-555-0100

You can have multiple Contact lines.

Pricing

Pricing: public          # prices listed on your website
Pricing: on-request      # contact us for a quote
Pricing: api https://api.example.com/openapi.json  # OpenAPI spec for pricing API
Pricing: catalog         # refer to the Catalog field

When using api, the URI must point to your API specification (OpenAPI 3.x recommended) or structured API documentation — not a raw endpoint URL. An agent reading this URI needs to be able to understand the full request structure from the document alone.

Ordering

Ordering: website https://example.com/shop         # self-serve checkout
Ordering: email                                    # send an email to Contact
Ordering: api https://api.example.com/openapi.json # OpenAPI spec for ordering API
Ordering: phone                                    # call the Contact number
Ordering: protocol                                 # handled by Commerce-Protocol endpoint

When using api, the URI must point to your API specification (OpenAPI 3.x recommended) or structured API documentation. An AI agent will read this document to understand how to construct a valid order request — method, path, payload schema, and expected response. A raw endpoint URL without schema information is not sufficient.

If your pricing and ordering are both described by a single API specification, you may use the same URI for both fields.

Use protocol when an agentic commerce protocol (declared via Commerce-Protocol) handles the full ordering and payment flow — no separate OpenAPI spec or checkout URL is needed.

Commerce-Protocol

Declare which agentic commerce protocols your store supports. This field is repeatable — add one line per protocol.

Commerce-Protocol: ucp https://shop.example.com/ucp       # Universal Commerce Protocol
Commerce-Protocol: acp https://api.example.com/acp/v1    # Agentic Commerce Protocol

When a Commerce-Protocol is declared, agents can use it for end-to-end purchases including payment. You should also set Ordering: protocol to indicate that the full ordering flow is handled by the protocol.

Interaction-Model

Declare how much human involvement your procurement flow requires:

Interaction-Model: automated          # fully autonomous — no approval needed
Interaction-Model: approval-required  # agent submits, human approves
Interaction-Model: human-led          # agent assists, human drives
Interaction-Model: hybrid             # automated below a threshold
X-Auto-Approve-Under: 10000 USD       # (for hybrid) threshold for auto-approval

This field helps agents decide whether to proceed autonomously or loop in a human before committing to a purchase.

Capability Fields

Declare each capability you support as its own field. Each takes the same three-tier value as Ordering and Pricing:

Quote: yes                                          # available — contact us to request
Quote: website https://example.com/request-quote    # use this form
Quote: api https://api.example.com/openapi.json     # fully automated via API

Invoice: yes
Tracking: api https://api.example.com/openapi.json
Returns: website https://example.com/returns
Subscription: yes
Rfq: yes

You only need to declare capabilities you support. Absent fields mean "not declared", not "not supported".

Keeping the File Current

Set the Expires field to prompt agents to re-fetch periodically:

Expires: 2027-01-01

Review and update the file whenever:

  • Your contact information changes
  • You launch or deprecate a purchasing API
  • Your pricing model changes
  • You add new capabilities (e.g., you build an order tracking integration)

Security Guidelines

What to include

Only include information you would publish on a public webpage. The file is publicly accessible without authentication.

What NOT to include

  • API keys, passwords, or tokens
  • Internal system details or IP addresses
  • Personally identifiable information beyond public contact addresses
  • False or misleading capabilities

Authentication

Use the Auth field to declare the authentication method your APIs require. This is a discovery hint only — it tells agents what kind of credentials to expect so they can prepare before fetching the full API specification.

Full authentication details (OAuth endpoints, API key headers, scopes) MUST be documented in the OpenAPI specification referenced by your api URIs. Agents will read the spec's securitySchemes to understand auth requirements.

Do not include credentials, API keys, or tokens in the procurement.txt file.

Canonical-Hash

If you serve procurement.txt through a CDN, reverse proxy, or caching layer, consider computing and publishing a Canonical-Hash. This allows agents to detect if the file has been modified after you published it.

Recompute and update the hash whenever you update the file. The Online Generator can compute the hash for you automatically.

Keep API URIs on the same domain

Where possible, host your API specifications on the same domain as your procurement.txt file. Cross-domain URIs are treated with additional caution by security-aware agents.

Cache-Control headers

Set appropriate Cache-Control headers on your procurement.txt file so that agents and proxies do not serve stale versions after you make updates:

Cache-Control: public, max-age=86400

Combined with the Expires field, this ensures agents pick up changes promptly.

Content-Type Header

Serve the file with:

Content-Type: text/plain; charset=utf-8

Most web servers do this automatically for .txt files. If your file is served with a different Content-Type, validators will warn about it.

Backward Compatibility

When new versions of the spec are released:

  • Continue serving a file with the latest version you support.
  • Do not remove fields that were valid in previous versions unless the new spec explicitly deprecates them.
  • Agents that support older versions will continue to parse the fields they understand.

Checking Your File

Use the validator on the homepage to check:

  • Your file is accessible at the expected URL
  • The file parses without errors
  • Your Agent Readiness score
  • Any warnings (wrong Content-Type, expiry issues, etc.)

Or use the API directly:

https://procurementtxt.org/api/validate?domain=yourdomain.example