procurement.txt Specification

Status: Draft Version: 0.4 Date: 2026-04-04 License: CC0 1.0 Universal (Public Domain Dedication)

1. Overview

1.1 Purpose

procurement.txt is a plain-text file that a business publishes at a well-known location on its website. The file provides machine-readable metadata about how AI agents and automated purchasing systems can discover pricing, initiate orders, negotiate terms, and escalate to a human when necessary.

1.2 Problem Statement

AI purchasing agents currently have no standardized, lightweight way to determine whether a merchant supports automated procurement, what purchasing workflows are available, or how to contact a human for complex transactions. Agents must resort to scraping, guessing, or per-vendor integration. This creates friction for both buyers and sellers.

procurement.txt solves this by giving merchants a single, static file they can create in minutes to declare their procurement capabilities.

1.3 Target Users

Merchants — any business that sells goods or services online, from sole proprietors to enterprises. A merchant authors and hosts the file.

Agents — AI systems, automated purchasing bots, procurement platforms, and any software that acts on behalf of a buyer. An agent discovers and reads the file.

1.4 Relationship to Existing Standards

procurement.txt follows the precedent set by robots.txt (RFC 9309), security.txt (RFC 9116), humans.txt, and llms.txt. It is a static, unauthenticated, plain-text file placed at a predictable path. It does not replace APIs, catalogs, or EDI systems — it provides a discovery layer that points agents toward those systems when they exist.

A site MAY publish both robots.txt and procurement.txt. The two files serve different purposes and do not conflict. robots.txt governs crawling permissions; procurement.txt governs procurement interaction.

A site SHOULD reference its procurement.txt file in its llms.txt file (if present) to help LLM-based agents discover it during context ingestion. See 2.4 for details.

Relationship to Agentic Commerce Protocols. Several agentic commerce protocols have emerged to handle end-to-end transactional flows, including Universal Commerce Protocol (UCP, created by Google) and Agentic Commerce Protocol (ACP, supported by OpenAI). These protocols are primarily designed for one-shot purchases with integrated payment handling. procurement.txt is complementary, not competing: it is a discovery layer that can point agents to any downstream protocol — including UCP or ACP endpoints — as well as to traditional APIs, human contacts, and B2B workflows. A Shopify merchant supporting UCP can declare that via procurement.txt. A B2B industrial supplier with a 30-day approval process can declare that too. The Commerce-Protocol and Interaction-Model fields allow merchants to express which protocols they support and how much human involvement their procurement flow requires, covering the full spectrum from fully automated consumer purchases to multi-step B2B negotiations.

2. File Location

2.1 Default Path

The file MUST be served at:

https://{host}/procurement.txt

2.2 Alternative Path

The file MAY additionally be served at:

https://{host}/.well-known/procurement.txt

If both locations exist, the root-level file (/procurement.txt) takes precedence.

2.3 Discovery Rules

1. An agent SHOULD first request /procurement.txt.
2. If that returns a non-200 status, the agent MAY request /.well-known/procurement.txt.
3. If neither location returns a 200 response, the agent MUST assume no procurement.txt exists and MUST NOT infer procurement capabilities.
4. The file MUST be served with a Content-Type of text/plain; charset=utf-8.
5. The file MUST be accessible without authentication.
6. The file SHOULD be served over HTTPS.

2.4 Advertising in llms.txt

llms.txt is a convention for listing a site's key resources in a plain-text file so that LLM-based agents can index them during context ingestion. Merchants SHOULD reference their procurement.txt file in /llms.txt to make it discoverable by agents that consult llms.txt before visiting a site.

The reference SHOULD appear under a clearly named section heading. Example:

# Acme Corp

> Acme Corp sells industrial components worldwide.

## Procurement

- [procurement.txt](https://acme.example.com/procurement.txt): Machine-readable procurement metadata — pricing, ordering, and contact information for automated agents.

The description field (after the colon) SHOULD briefly describe the merchant's procurement capabilities so that agents can decide whether to fetch the full file. A minimal valid reference omits the description:

- [procurement.txt](https://example.com/procurement.txt)

If the merchant does not yet have a llms.txt, they MAY create a minimal one that only lists the procurement file:

# Example Corp

## Procurement

- [procurement.txt](https://example.com/procurement.txt): Procurement metadata for AI agents.

3. File Format

3.1 Syntax

procurement.txt uses a line-oriented, key-value format inspired by security.txt (RFC 9116).

• Each directive occupies one line.
• A directive consists of a field name, followed by a colon (:), followed by a space, followed by a value.
• Field names are case-insensitive. Agents SHOULD treat Contact and contact identically.
• Lines beginning with # are comments and MUST be ignored by parsers.
• Blank lines are permitted and MUST be ignored.
• Long values MUST NOT be split across lines. Each directive is a single line.

# This is a comment
Field-Name: value

3.2 Encoding

Files MUST be encoded in UTF-8. A byte order mark (BOM) SHOULD NOT be present.

3.3 Versioning

Every file MUST include a Version field. This specification defines version 1. Future versions will increment this integer.

Agents encountering an unrecognized version SHOULD attempt best-effort parsing and MUST NOT treat the file as invalid solely because the version number is higher than what they support.

3.4 URI Semantics for api Keywords

When the api keyword is used in any field value (e.g., Ordering: api, Pricing: api, Quote: api, Tracking: api), the accompanying URI MUST point to a machine-readable API specification or structured API documentation — it MUST NOT be a raw API endpoint.

An OpenAPI 3.x specification is the strongly recommended format. An agent resolving this URI SHOULD be able to determine the full request structure — method, path, parameters, authentication, and response schema — from the document at that URI alone, without any prior knowledge of the API.

Merchants whose fields are all described by a single API specification MAY use the same URI across multiple fields.

# Correct — URI points to an OpenAPI specification
Ordering: api https://api.example.com/openapi.json
Pricing:  api https://api.example.com/openapi.json
Quote:    api https://api.example.com/openapi.json

# Also acceptable — URI points to structured API documentation
Ordering: api https://api.example.com/docs/ordering

4. Core Fields (v1)

The full field table and value definitions are in the Fields Reference.

5. Field Definitions

Full definitions, allowed values, and examples for each field are in the Fields Reference.

6. Examples

See the Examples page for sample files covering common use cases: minimal setup, wholesale B2B supplier, SaaS company, and freelancer.

7. Extensibility

Merchants MAY define custom fields using the X- prefix (e.g., X-Lead-Time-Days: 5). Agents MUST ignore unrecognized fields. See the Fields Reference — Extensibility section for details.

8. Agent Behavior Guidelines

See the Agent Guide for implementation guidance covering discovery, parsing, API URI handling, caching, escalation, rate limiting, security, and readiness scoring.

9. Merchant Implementation Guidelines

See the Merchant Guide for step-by-step publishing guidance, field recommendations, security guidelines, and best practices.

10. ABNF Grammar

An informative ABNF grammar (RFC 5234) for the file format is in the ABNF Grammar appendix.

11. Security Considerations

11.1 File Integrity

procurement.txt is served as a plain-text file over HTTPS and is not cryptographically signed. Agents MUST follow these guidelines:

• Agents MUST only fetch procurement.txt over HTTPS.
• Agents SHOULD verify that the domain serving the file matches the merchant they intend to transact with.
• Agents SHOULD flag or refuse to act on procurement.txt files where API URIs point to domains that differ from the file's host domain, unless the agent has been explicitly configured to trust cross-domain references.
• Agents MUST NOT auto-execute financial transactions (purchases, payments, commitments) based solely on procurement.txt without human authorization or a pre-configured trust policy.

11.2 Canonical-Hash Field

The optional Canonical-Hash field allows agents to verify that a file has not been modified after the merchant published it.

How it is computed (by the merchant):

1. Compose the complete procurement.txt file with all intended fields.
2. Compute a SHA-256 hash of the file content with the Canonical-Hash line removed (or its value set to the empty string), with line endings normalized to LF.
3. Add Canonical-Hash: sha256:<hex-digest> to the file.

How it is verified (by agents):

1. Fetch the file.
2. Remove the Canonical-Hash line (or replace its value with empty string).
3. Normalize line endings to LF.
4. Compute SHA-256 of the remaining content.
5. Compare with the declared hex digest.

This field is not a cryptographic signature — it does not prove who authored the file. It detects post-publication modification (e.g., if the file was altered after being cached or proxied). It is a lightweight integrity check analogous to Subresource Integrity (SRI) in browsers.

Agents SHOULD treat a Canonical-Hash mismatch as a warning, not a hard failure. The merchant may have updated the file without yet recomputing the hash.

Canonical-Hash: sha256:a1b2c3d4e5f6...

11.3 Agent Security Best Practices

• Never auto-execute purchases without human confirmation or a pre-approved trust policy.
• Treat cross-domain API URIs with suspicion — flag them for human review before executing transactions.
• Validate the Canonical-Hash if present; warn (but do not hard-fail) if it does not match, since the merchant may have updated the file without recomputing the hash.
• procurement.txt is unsigned and unauthenticated — domain trust via HTTPS is the primary trust signal.
• Do not follow redirects from procurement.txt URLs to different domains without flagging the redirect to the user.

11.4 Merchant Security Best Practices

• Compute and include the Canonical-Hash field, especially if you serve the file through a CDN or proxy.
• Keep API specification URIs on the same domain as the procurement.txt file when possible.
• Set appropriate Cache-Control headers to prevent stale cached versions from being served after updates.
• Never include API keys, passwords, tokens, or other secrets in the file.

12. Version 1 Scope

The following items are explicitly out of scope for version 1. They may be addressed in future versions.

• Structured catalog formats. The Catalog field points to an external resource; this specification does not define the catalog's schema.
• Payment execution. The Payment-Terms field declares accepted payment methods but does not handle payment processing, settlement, or financial transactions.
• Contracts and legal terms. The file does not communicate terms of service, warranty, or liability.
• Digital signatures. The file is not signed or verifiable. The Canonical-Hash field provides lightweight integrity checking but is not a digital signature. Full cryptographic signing may be addressed in a future version.
• Multi-tenant or multi-storefront support. The specification assumes one file per domain.
• Agent identification or registration. There is no mechanism for agents to identify themselves to merchants via this file.
• Webhook or callback mechanisms. The file is static and pull-based only.
• Tax and currency details. The Min-Order field includes a currency code, but detailed tax calculation, multi-currency pricing, and exchange rate handling remain out of scope.
• Access control. The file itself is always public. Per-agent permissions are out of scope.
• Internationalized field names. Field names are ASCII-only. Values may contain UTF-8 text.
• JSON or XML alternative formats. Version 1 defines only the plain-text format.