Skip to main content

Reviews, Acceptance, Partials

Structured review loop, partial acceptance, split releases, and milestone changes.

C
Written by Catalin Fetean
Updated over 3 weeks ago

Audience: Reviewers, PMs, Contributors, Finance, Legal
Outcomes: Predictable review cycle; faster partial payouts; clean scope control

Accept / reject

# Accept curl -X POST $API_BASE/api/orders/ord_123/deliverables/dlv_456/accept -b cookies.txt # Reject (with reason) curl -X POST $API_BASE/api/orders/ord_123/deliverables/dlv_456/reject -b cookies.txt \ -H 'Content-Type: application/json' \ -d '{"reason":"Replace hero image with 2x retina asset and fix padding."}'
  • Resubmission uploads a new version; thread stays intact

  • Status: submitted → rejected → submitted → accepted

  • Notifications: email + in-app + SSE (deliverable.accepted, deliverable.rejected)

Partial acceptance & split releases

curl -X POST $API_BASE/api/escrow/release -b cookies.txt \ -H 'Content-Type: application/json' \ -d '{"orderId":"ord_123","milestoneId":"m1","amount":25000}'
  • Multiple partial releases allowed; all logged

  • Never exceed remaining milestone balance

Change requests: add/edit/remove milestones

  • Small changes: add a milestone or adjust amount; keep a note

  • Contractual changes: create a contract amendment first

  • Guardrails: new total must equal sum of milestone amounts; releasing beyond total is blocked

  • Visibility: counterparty is notified and must accept material changes

QA checklist

  • Rejection requires reason; acceptance triggers events & (optional) release request

  • Changing milestone totals revalidates order sum

Runbook: “Counterparty can’t see deliverable”

  • Ensure order is shared and they’re in the correct org context; verify partner link

Did this answer your question?