Assinafy Contracts API

Contract terms tracked on documents: counterparty, value, dates and renewal terms. A contract always belongs to a document of the workspace, and tracking it never changes how that document is uploaded, sent or signed. ### How the flow works 1. **Have the document first.** Upload it with `POST /v1/accounts/{accountId}/documents`, or pick one already in the workspace, and keep its `id`. No call creates a document and its contract terms together. 2. **Set its terms.** `PUT /v1/accounts/{accountId}/documents/{documentId}/contract` with the terms. Any time: right after the upload, while the document is out for signature, or long after it was signed. A contract that ended before it was tracked is registered as it ended (`expired` with a past `end_date`, or `terminated`). A cancelled, declined or expired document takes no new terms. If this call fails, the document stays uploaded and the terms can be sent again. 3. **Record a change with a signed instrument** (optional). Upload the amendment, renewal or termination document, then `PUT` its own `.../contract` with `parent_document_id` (the contract's document), `relation_type` and the terms it changes. The change applies to the contract once that document is signed (at once if it already is), and `document_contract_amended` is recorded. 4. **Let the hourly run keep it current.** Every active contract is walked by the Brasília calendar day: the renewal notice when the notice period starts, warnings 45 and 30 days before the end date, and, the day after it, the next term for an auto-renew contract or `expired` for the others. Each records its `document_contract_*` event and e-mails the contract's owner. The same run hands the contracts of an owner who left the workspace, however they left, to the first owner still an active member. 5. **Or change it directly.** `PUT` edits the terms, `POST .../renew` starts the next term and `POST .../terminate` closes the contract. 6. **Read it.** `GET /v1/accounts/{accountId}/contracts` lists the workspace's contracts; `GET .../documents/{documentId}/contract` reads one with its amendments; `GET /v1/documents/{documentId}` says whether a document has one (`has_contract`). Every change is an event on the document's activities and a webhook. ### Who can write Writes need a plan with contract tracking; reads do not. Any active member of the workspace, owner or organizer, may set terms, link amendments, renew and terminate; an OAuth app needs `documents:write` to write and `documents:read` to read. ### Errors and conflicts A refused write lists every problem in `errors`, each with its `field` and a stable `code`; the codes and the rules behind them are in the `400` response. A write that sends the `updated_at` it read is refused with `409` if the contract changed meanwhile. ### When the plan lapses While the workspace's plan lacks contract tracking (its subscription expired or was cancelled; a payment past due inside the grace period keeps it), the hourly run leaves its contracts as they are and signed amendments wait. The first run after the plan returns catches up: a contract past its end date moves to the term running that day, on its own renewal cycle, or expires; waiting amendments apply in signing order; alerts whose window passed meanwhile are not sent.