Connect an agent to an agreed delivery.

Use CREATE_DRAFT to prepare a complete buyer agreement draft or supplier proposal draft for human review. Dates, original-file arrangements, contract references and requirements use the same editor fields. Preparation does not send, agree, accept, sign or pay.

POST /api/agents/v1/drafts

Save the request ID and reuse the same payload if the response is uncertain. Open the returned humanUrl to review the draft before sending an agreement.

OpenAPI contract · Create an agreement

Enable CREATE_PROJECT in agent access. Creation commits a buyer agreement; it is not a private draft. A human invites the supplier.

1. Replace the example parties, scope, dates, criteria and original-storage terms. Explicitly choose the purpose, contract basis and sharing policy. The example uses TEST; do not use example terms for a real commitment.
2. Run prepare-create. It reads the current documents, previews the exact confirmation and saves the complete input locally. This creates no agreement and records no consent.
3. Review every term, the current service documents and the displayed confirmation. Only after explicit approval, run create with that same file. Keep it unchanged for retries after an uncertain response.
4. Open the returned humanUrl to invite the supplier. After human action, reread the project before planning another command.

node agent-client.mjs prepare-create agent-project.json prepared-project.json
# Review prepared-project.json and the displayed confirmation before continuing.
node agent-client.mjs create prepared-project.json

For raw HTTP, send the complete prepared file to POST /api/agents/v1/projects. Required fields include baselineStatement, termsPolicy, legalContext with current documents, and confirmationDigest from the preview.

First read GET /api/acceptance/legal-config, then POST /api/acceptance/confirmation-preview with legalContext and operation AGREEMENT. OpenAPI includes both public preparation operations with a root server URL and no credential requirement.

If documents change before submission, prepare a new file from the unprepared input and review again. Do not update a saved retry payload automatically.

Full public workflow guide · OpenAPI contract

Use separate CREATE_PROPOSAL, UPDATE_PROPOSAL, PUBLISH_PROPOSAL, RESPOND_PROPOSAL and WITHDRAW_PROPOSAL permissions through /api/agents/v1/proposals. Each write checks the exact proposal version and current authorization.

Publishing gives the named buyer a review URL; it does not send an invitation email or accept the proposal. Buyer acceptance creates the final agreement. The supplier must separately confirm that version before submitting materials.

Supplier proposal guide · OpenAPI contract

Both parties can work from the same versioned agreement. The supplier submits the delivered version and materials. The buyer reviews each criterion and makes the completion decision. Agent permissions narrow what an automation may do within that flow; they do not transfer the other party’s commitments.

Use one agreed project and grant only submission access. The buyer continues to review in their own workspace and makes the completion decision. No new decision or payment permissions are added.

Import each JSON file into n8n. In each HTTP Request node, select a Header Auth credential with name Authorization and value Bearer <your scoped agent credential>. Never put the credential in the input, workflow export or material references.

Map a single project and its actual materials in Input. Preparing makes no submission: save its entire output in your existing durable job store before running Submit. Retries must reuse that saved envelope, including its request ID. Do not prepare again after an uncertain send.

Read decision returns the current state and exact references; it does not accept work, independently verify quality or move money. Run it from your existing workflow when a status check is needed. There is no automatic polling schedule.

A project read returns project, automation, humanUrl, availableActions, and blockedActions. A blocked action includes its reason, WAIT_FOR_HUMAN, requiredHumanAction and humanUrl. Required signatures must be completed in the human signing workspace; reread after human action. A human also manages the separate Signed Delivery service quote and payment. A record credit does not buy external signatures. The available actions are hints; current permissions, dates, confirmations, and material requirements still apply.

Every project command binds to the current project.headEventHash and automation.revision. Persist the entire envelope with a stable UUIDv4 request ID before sending.

{
  "expectedEventHash": "exact current project.headEventHash",
  "automationRevision": 0,
  "input": {
    "requestId": "a fresh UUIDv4 for this action",
    "reason": "Explain the operation"
  }
}

Try a deliberate handoff

This example is a write: it pauses agent actions and leaves a note for the human. Use a selected test project with at least one granted write action. Save the following as handoff.json:

{"reason":"Please review the materials before automation continues."}

node agent-client.mjs prepare delivery_YOUR_UUID handoff handoff.json pending-handoff.json
# Review pending-handoff.json before running the next command.
node agent-client.mjs send delivery_YOUR_UUID handoff pending-handoff.json

The prepare command writes a new file without overwriting an existing one. After an uncertain network result, retry the same saved envelope and request ID. A successful replay does not create a second business event. Changed content under the same ID is rejected.

Recover with the right next step

Error responses include error, retryable: false, and nextAction. Do not blindly retry validation errors or overwrite the expected head of a queued command. A failed notification does not undo a saved decision; use workspace notification controls instead of repeating the decision.

Scroll the table horizontally to see all columns →

Business commands retain their checks

Creating an agreement commits a buyer–supplier agreement, not a private draft. The API can create a buyer-side project when the credential has CREATE_PROJECT; supplier-led drafts and invitations remain in the human workspace. Current documents are at the legal configuration endpoint; the agreement requires reviewed terms, legal context, and its exact confirmation digest. Never manufacture consent. Use the returned human URL to invite the supplier.

Submitting identifies the exact agreement, prior submission or review when applicable, and one material set per criterion. Include original-file references, names, byte sizes, and SHA-256 fingerprints; a fingerprint alone does not establish access or correctness.

Accepting requires every criterion to be met, the exact submission and checked original files, and the applicable acceptance confirmation. A general review permission is insufficient.

Start with the first-agreement example and read access before enabling decisions. Full public workflow guide · Contact support

• Project polling and authorized event webhooks are supported. This version does not provide a workflow scheduler or an MCP endpoint.
• Supplier-led drafts, invitations, replacement agreement terms, receipt sharing, and final concern resolution remain in the human workspace.
• Handoff notes appear in the project. When project emails are enabled and the current recipient is eligible, Prooftask can send a reminder. Email delivery does not complete the handoff.
• An agent cannot issue credentials, manage users, elevate authority, or resume itself.

Evaluating a production API integration as a deliverable? That is a separate acceptance workflow with agreed technical evidence. Review its preparation requirements.