ACP Custom Extension Authoring
Before writing code
Fetch live docs:
- Web-search
site:github.com agentic-commerce-protocol rfcs extensionsfor the extensions framework RFC - Web-search
site:github.com agentic-commerce-protocol examplesfor extension examples - Fetch
https://developers.openai.com/commerce/specs/checkout/for how extensions integrate with checkout - Study the built-in discount extension as a reference: web-search
site:github.com agentic-commerce-protocol rfcs discount_extension
Conceptual Architecture
What Extensions Are
Extensions are composable, optional add-ons that augment ACP's core capabilities. They allow the protocol to grow without bloating the core spec — new features are added as extensions with independent lifecycles.
Extension Properties
Every extension defines:
- Name — Core extensions use simple names (
discount); third-party use reverse-domain (com.example.loyalty) - Version — Calendar versioned (
YYYY-MM-DD) - Parent capability —
extendsfield linking to the parent (e.g., extendscheckout) - JSONPath targets — Where in the core schema this extension adds fields
- Schema — JSON Schema for the extension's data
JSONPath Targeting
Extensions use JSONPath (RFC 9535) to inject fields into core schema locations:
$.CheckoutSessionCreateRequest.discounts— Add fields to the create request$.CheckoutSession.discounts— Add fields to the response- Multiple targets per extension are allowed
Extension Lifecycle
draft → experimental → stable → deprecated → retired
- draft — In development, not for production
- experimental — Available for testing, may change
- stable — Production-ready, backwards-compatible changes only
- deprecated — Still functional, but replacement available
- retired — No longer supported
Schema Composition Rules
- Extension schemas are composed alongside (not inside) core schemas
- Extensions must not conflict with core fields
- Extensions must not introduce authentication bypasses
- Extension data follows the same PCI/PII rules as core fields
- Extensions can reference other extensions (dependency chain)
Naming Conventions
- Core extensions: Simple lowercase names —
discount,intent_traces,affiliate_attribution - Third-party: Reverse-domain notation —
com.mycompany.loyalty,io.myplatform.subscription
Built-in Extensions as Reference
Study these before authoring custom extensions:
- Discount — Discount codes, applied/rejected discounts, allocations
- Intent Traces — Cart abandonment signals with reason codes
- Affiliate Attribution — Privacy-preserving attribution tracking
Custom Extension Ideas
- Loyalty program integration
- Subscription management
- Gift wrapping options
- Delivery instructions
- Tax exemption certificates
- Custom buyer preferences
Best Practices
- Start in
draftlifecycle, graduate throughexperimentaltostable - Use reverse-domain naming for all non-core extensions
- Define clear JSON Schemas with validation rules
- Document the extension's purpose, fields, and interaction with core checkout
- Test that your extension survives capability negotiation pruning
- Version independently from the core protocol
Fetch the extensions framework RFC for the exact extension manifest structure, JSONPath targeting syntax, and schema composition rules before implementing.