Agreements API

The Agreements API is the product integration layer around Agreements Protocol. It gives applications a stable way to turn agreement definitions into deployed, monitored, participant-facing workflows without making every product own contract orchestration, indexing, notification routing, and lifecycle state. The API does not define what an agreement means. Agreement semantics come from the agreement data standard and from the execution engine that interprets those definitions. The API makes those protocol objects usable inside real products. Use the API layer when you want agreement correctness and verifiable execution to show up as ordinary application capabilities: create agreements, attach participants, deploy with signed authorization, read state, submit participant inputs, inspect history, and trigger downstream product behavior.

​

Why the API matters

Agreements Protocol separates agreement semantics from application delivery. The data standard gives every agreement a uniform language. The onchain execution engine gives deployed agreements constrained, verifiable state transitions. The API connects those layers to the systems where users actually create, accept, operate, and monitor agreements. That matters because most products need more than a contract call. They need draft records, participant context, observers, validation feedback, deployment preflight, state reads, input history, authorization, and notifications. The API provides that supporting layer while keeping the protocol semantics anchored in the agreement definition and execution engine.

​

What the API adds

​

The value for product teams

The API lets product teams build agreement experiences around a common execution model instead of rebuilding agreement infrastructure for every workflow.

• A marketplace can use the same agreement model for milestone acceptance, rejection, resubmission, and completion.
• A service platform can expose participant actions while preserving state transitions that are constrained by the deployed agreement.
• An operations product can monitor agreement status, history, observers, and notifications without becoming the source of truth for the agreement lifecycle.
• An API integration can use typed client methods and raw API references without depending on private implementation details of the execution engine.

The result is a cleaner boundary: products own user experience, identity context, notifications, and business operations; the agreement definition and execution engine own the explicit agreement path.

​

How it preserves trust

The API is designed to support the trust guarantees of the protocol, not replace them.

​

Where it sits in the system

This keeps the core design minimal and composable. Agreement correctness lives in the definition and execution path. The API adds application convenience, workflow coordination, and legibility around that core.

​

When to use the API

Use the API when your integration needs any of the surrounding product behavior that most agreement workflows require:

• hosted agreement records and queries
• draft-to-deployment workflows
• validation and deployment preflight
• participant and observer context
• signed deployment or signed participant inputs through SDK helpers
• current state, input history, and lifecycle monitoring
• notifications or application integrations triggered by agreement movement

Use the direct onchain path when your system deliberately wants to own wallet orchestration, RPC access, contract interaction, indexing, and product workflow state itself. For most application integrations, the API is the more practical surface because it packages the repeated work around the same verifiable agreement core.

​

What to read next