Agent Commerce API

An agent commerce API for teams that need structured orders, refunds, invoice collection, and checkout state that an AI system can reason about safely.

Flint already publishes order-first public APIs, an OpenAPI spec, and a single-file `SKILL.md` reference designed for coding agents and API tooling.

Orders, refunds, hosted checkout, invoices, and subscriptions all stay on semantic business objects instead of forcing agents to infer meaning from raw payment amounts and metadata.

The public docs explain state machines, retry behavior, and object relationships directly, which reduces the ambiguity that usually makes agent-driven commerce risky.

Workflow Outline

Your team wants agents to work on real commerce objects like orders, refunds, invoices, and hosted collection state instead of raw charge records.

You need machine-readable API schemas and compact reference material so coding agents can stay aligned with the public contract.

Support, finance, or workflow automation should be able to read one business record before deciding what action to take next.

What This Solves

Teams searching agent commerce APIs usually want more than payment execution. They need structured business objects, explicit lifecycle state, and documentation an AI agent can consume without guessing field names or workflow meaning.

Step 1

Order-aware support agents

Let an agent inspect the order, linked payment IDs, refund history, and next actions before suggesting or taking a support-side action.

Step 2

Workflow automation against real business objects

Drive checkout follow-up, balance recovery, or invoice actions from semantic order and invoice state rather than charge metadata.

Step 3

Tool-router-friendly commerce actions

Give coding agents structured docs and schemas so tool calling stays aligned with actual field names, object relationships, and valid lifecycle moves.

Step 4

Safer post-payment operations

Make refund and collection actions easier to reason about by attaching them to the same order record instead of reconstructing context after the fact.

Why Flint Fits

Flint already publishes order-first public APIs, an OpenAPI spec, and a single-file `SKILL.md` reference designed for coding agents and API tooling.

Orders, refunds, hosted checkout, invoices, and subscriptions all stay on semantic business objects instead of forcing agents to infer meaning from raw payment amounts and metadata.

The public docs explain state machines, retry behavior, and object relationships directly, which reduces the ambiguity that usually makes agent-driven commerce risky.

Choose Another Path When

Use the tool-callable page when the main question is API schema and tooling format rather than commerce workflows broadly.

Use the AI Payments flagship page when you want Flint's broader AI-facing product narrative instead of the narrower agent-operable API story.

Use support-agent pages when the workflow is specifically refund, invoice, and support operations rather than general agent-ready commerce architecture.

Implementation References

Reference the exact flow surfaces

LLM Integration

Reference for using Flint's `SKILL.md` and OpenAPI spec with coding agents and AI tooling.

Orders API

Inspect the semantic order object that gives agents durable business context.

OpenAPI

Download the public OpenAPI spec for structured tool calling, code generation, and agent tooling.

Explore tool-calling, support workflows, and Flint's AI-facing model

These pages narrow the next decision once you know the API needs to be readable and operable by agents rather than only by human developers.

Tool-Callable Commerce API

Use this when the main question is how Flint's public contract fits agent tooling and structured tool calling.

Commerce API for AI Support Agents

Use this when the current workflow is support-focused rather than general agent-readability and orchestration.

AI Payments

Go broader when the question is Flint's overall AI-facing payment and order model rather than agent-operable API shape specifically.

Next Step

Ship the workflow before polishing the edge cases

Start with the underlying Flint flow, then layer your product-specific UX and recovery paths on top.