procurement.txt

Changelog

All notable changes to the procurement.txt specification will be documented here.

v0.4 — 2026-04-04

Additive changes. No breaking changes.

Added: Commerce-Protocol field

Declares support for agentic commerce protocols such as Universal Commerce Protocol (UCP, created by Google) and Agentic Commerce Protocol (ACP, supported by OpenAI). This field is repeatable — add one line per protocol. Each value names the protocol and provides the endpoint URI.

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

When a Commerce-Protocol is declared, Ordering: protocol may be used to indicate that the full ordering flow (including payment) is handled by the protocol.

Added: Interaction-Model field

Declares the expected level of human involvement in procurement. Helps agents determine upfront whether they can complete a transaction autonomously or must involve a human.

KeywordMeaning
automatedFully automated; no human approval required
approval-requiredAgent prepares the order; human must authorize
human-ledAgent assists with discovery; human drives the transaction
hybridAutomated below a threshold (use X-Auto-Approve-Under to express)
Interaction-Model: automated
Interaction-Model: hybrid
X-Auto-Approve-Under: 10000 USD

Added: Ordering: protocol keyword

New keyword for the Ordering field. Used when ordering is handled entirely through a declared Commerce-Protocol endpoint — no separate OpenAPI spec or checkout URL is needed.

Added: llms.txt advertising (Section 2.4)

Merchants SHOULD reference their procurement.txt file in their llms.txt file (if present) to make it discoverable by LLM-based agents during context ingestion.

Updated: Agent Readiness scoring

HIGH now also accepts a Commerce-Protocol field as sufficient (it subsumes both Ordering and Pricing by providing a complete transactional flow). Interaction-Model now counts toward HIGH+ alongside Service-Region, Payment-Terms, Auth, and Min-Order.

HIGH+  — HIGH + at least two of: Service-Region, Payment-Terms, Auth, Min-Order, Interaction-Model
HIGH   — valid file + (Ordering + Pricing) OR Commerce-Protocol
MEDIUM — valid file + Ordering and/or Pricing
LOW    — valid file with only Version and Contact
NONE   — invalid or missing

Added: New examples

New example files added for B2C retail with UCP (Section 9), enterprise SaaS with ACP and B2B fallback (Section 10), and freelancer/consultant (Section 11). Existing examples updated to include Commerce-Protocol and Interaction-Model where appropriate.

Updated: Relationship to Agentic Commerce Protocols

New section in the Overview (1.4) explaining the relationship between procurement.txt and agentic commerce protocols (UCP, ACP), clarifying that procurement.txt is a complementary discovery layer.

v0.3 — 2026-03-29

Additive changes. No breaking changes.

Added: Service-Region field

Declares the geographic regions a merchant serves. Accepts a comma-separated list of ISO 3166-1 alpha-2 country codes or the keyword global. Absent means geographic availability is unknown.

Service-Region: US, CA, MX
Service-Region: global

Added: Min-Order field

Declares a minimum order value. Previously used as the example extension field X-Min-Order; promoted to core because minimum order thresholds are common enough in B2B procurement to warrant standardization.

Min-Order: 500 USD
Min-Order: none

Added: Payment-Terms field

Declares accepted payment methods and terms. Critical for B2B workflows where net terms, purchase orders, and trade credit are standard. Accepted keywords: prepaid, net-30, net-60, net-90, purchase-order, credit-card, wire, on-account.

Payment-Terms: net-30, wire, purchase-order

Added: Auth field

Re-introduced as a discovery hint for agents. Declares the authentication method(s) required to use the merchant's APIs, so agents can prepare credentials before fetching the full OpenAPI specification. Full auth details remain in the referenced OpenAPI spec. Accepted keywords: none, api-key, oauth2, basic, custom.

Auth: api-key

Added: Canonical-Hash field

Optional SHA-256 integrity hash of the file (computed with the Canonical-Hash line itself removed). Allows agents to detect post-publication modification when files are served through CDNs, proxies, or caches. Not a cryptographic signature — domain trust via HTTPS remains the primary trust signal.

Canonical-Hash: sha256:a1b2c3d4e5f6...

Added: Section 11 — Security Considerations

New normative section covering file integrity requirements, Canonical-Hash computation and verification, agent security best practices, and merchant security best practices.

Updated: Agent Readiness scoring

Added HIGH+ tier above HIGH. A merchant achieves HIGH+ when they have a valid file with Ordering + Pricing and at least two of: Service-Region, Payment-Terms, Auth, Min-Order.

HIGH+  — HIGH + at least two of: Service-Region, Payment-Terms, Auth, Min-Order
HIGH   — valid file + Ordering + Pricing
MEDIUM — valid file + Ordering and/or Pricing
LOW    — valid file with only Version and Contact
NONE   — invalid or missing

Updated: Version 1 Scope (out-of-scope list)

  • Replaced "Payment processing" with "Payment execution" — Payment-Terms declares accepted methods but does not handle settlement.
  • Replaced "Currency or tax information" with "Tax and currency details" — Min-Order includes a currency code, but exchange rates and tax calculation remain out of scope.
  • Added note to "Digital signatures" item: Canonical-Hash provides lightweight integrity checking but is not a digital signature.

Updated: Examples

All example files updated to include new fields. X-Min-Order replaced by core Min-Order field. Extension field example updated to use X-Lead-Time-Days and X-Sustainability-Cert.

v0.2 — 2026-03-28

Breaking changes.

Removed: Capabilities field

The Capabilities: quote, invoice, tracking comma-list has been removed. Each capability is now its own field, following the same value pattern as Ordering and Pricing:

Quote: yes
Invoice: website https://example.com/invoices
Tracking: api https://api.example.com/openapi.json

The six capability fields are: Quote, Invoice, Tracking, Returns, Subscription, Rfq.

Each accepts yes (contact to initiate), website <URI> (web form or portal), or api <URI> (OpenAPI 3.x spec). This allows each capability to express both whether it is supported and how to access it — consistent with how Ordering and Pricing already work.

Removed: Auth field

The Auth field has been removed. Authentication requirements are encoded in any OpenAPI specification referenced by an api URI. Agents should read auth requirements (securitySchemes, security) from the spec at the api URI rather than from a separate field in the procurement.txt file.

Updated: Agent Readiness scoring

HIGH now requires Ordering + Pricing only. Previously Capabilities was also required. Individual capability fields are bonus detail, not a readiness gate.

HIGH   — valid + Ordering + Pricing
MEDIUM — valid + Ordering or Pricing
LOW    — valid + required fields only
NONE   — invalid or missing

Migration

Files using the old Capabilities or Auth fields will continue to parse without error — the parser accepts unknown fields silently. To update an existing file:

  1. Replace Capabilities: quote, invoice with individual lines like Quote: yes and Invoice: yes.
  2. Remove the Auth: line. If you previously pointed to OAuth2 or API key documentation, that information should live in your OpenAPI specification.

v0.1 — 2026-03-23

Initial draft.

This is the first public draft of the procurement.txt specification.

What's included

  • Core file format specification (line-oriented key-value, UTF-8, comments)
  • File location specification (/procurement.txt with /.well-known/procurement.txt fallback)
  • 12 core fields: Version, Contact, Pricing, Ordering, Negotiation, Rate-Limit, Auth, Capabilities, Escalation, Catalog, Expires, Preferred-Languages (note: Auth and Capabilities removed in v0.2)
  • Extension field convention (X- prefix)
  • Agent behavior guidelines (discovery, parsing, caching, escalation, rate limits)
  • Merchant implementation guidelines
  • Security considerations
  • Informative ABNF grammar
  • Reference parser implementation in TypeScript (@procurement-txt/parser)
  • Validator web tool and API

Design decisions

Why plain text? Following the precedent of robots.txt and security.txt, a plain-text format lowers the barrier to adoption. Any business can create a valid file in a text editor without any tooling.

Why not JSON? JSON requires a parser and is less readable at a glance. The plain-text format is intentionally simple to encourage adoption. JSON may be explored in a future version.

Why Version: 1 and not 0.1? The Version field is the file format version, not the spec draft version. Version 1 is the first stable format. When the format changes in a breaking way, the version will increment to 2.

Why is Contact required? Every procurement interaction ultimately involves a human at some point. Requiring at least one Contact ensures agents always have a fallback path for edge cases that automation cannot handle.

Future

Items being considered for future versions:

  • v1.0 — formal IANA registration for the well-known URI
  • v2.0 — structured catalog format recommendation
  • Possible JSON alternative format
  • Digital signature support (PGP or similar)
  • Multi-storefront / subdomain support