Changelog

v1 changes additively: fields and endpoints may be added, and the version rises with them. Nothing is removed or renamed inside v1, so an integration written against today’s contract keeps working. Every response tells you which version answered it, in Rivet-Api-Version.

Deployed here: v1.21.0

1.21.0The Share family. POST /v1/share/items adds an HTML page (kind html: the whole document, UTF-8, up to 4 MB) or a link (kind link: an https url) to the share drive of the person who created the key, and GET /v1/share/items/{itemId} reads one back, with whether a page has passed its malware scan (status scanning, then ready). Both need the new scope share:write and act as that person, the one exception to a key acting as its organization: they must still be able to share for the organization, and the item is theirs, restricted, for them to share. Answers never carry an item's address, which holds its share token; drive_url says where the person shares it. A sandbox organization has no drive (capability_unavailable). Over MCP the two are createShareItem and getShareItem; the family sits behind API_SHARE_ENABLED.

1.20.0Gate passes and claims. The document types gate_pass and claim join the type and status enums, and origin gains workflow (a pass a workflow issued itself). POST /v1/documents builds a gate pass from a bill of sale, invoice or purchase order on the same connection (source_document_type, source_document_id): its goods are the source's product lines with their identifiers (VIN, stock and lot numbers, mileage, color); it never carries a price and takes no line_items, and it is issued with a pickup location and a valid_until still ahead. A claim asks the other party for a remedy: the documents it is about (subjects), a category (other with category_text), a statement and what it asks for (requested); it takes no line_items, and its decision is the other party's, never part of creating it. Reads gain a gate_pass block and a claim block, with the claim's decision as the claimant reads it — remedy, amount, reason and when — for either party.

1.18.0Rivet Money (simulated) in the sandbox. PUT /v1/sandbox/money turns it on or off: Treasury accounts with balances, Wallet payment methods, Cards and payments through Rivet between sandbox organizations, all simulated — nothing reaches a bank. It turns on only while the organization that owns the sandbox is verified by Rivet; until then it answers the new error code owner_not_verified (403), and it reads off whenever the organization is not verified. The sandbox's state gains money (enabled, available, reason). Document payments through the API stay simulated in the sandbox either way.

1.17.0POST /v1/documents/{id}/pay takes the signed PaymentPayload in the body as payment, beside payment_method usdc: the twin of PAYMENT-SIGNATURE for callers that cannot set headers, such as the MCP server (the header wins when both are sent; the key's payment_limits apply). Webhook deliveries of an invoice to its payer carry pay_url — null on the send's own delivery, present from the next event on. A draft is the issuer's alone: the counterparty's webhooks hear nothing and its reads answer not_found until the draft is sent, when the counterparty receives document.created. GET /v1/enablement gains a money family (whether Rivet Money is live here), and FinanceSetup gains money_ready. advanceSandboxCounterparty takes only the edges the counterparty may take, and confirms a scheduled payment as paid. Dedupe webhooks on the event's id; descriptions now say what the code does (reads and writes, key rotation, ES256 attestations).

1.16.0Pay by agent (x402 v2): GET /v1/pay/{payRef} answers an invoice's challenge (402 with PAYMENT-REQUIRED), and POST /v1/pay/{payRef} settles it in USDC on Base, payer → payee, with no account or key. POST /v1/documents/{id}/pay gains payment_method usdc, the authenticated twin. New error codes: payment_required, payment_amount_stale, approval_required, not_payable, financed_invoice_rivet_rail_only, x402_settle_failed, x402_already_settled.

1.15.0Line kinds: a line is an item (quantity × unit price, its own discount and tax) or a discount, fee or tax adjustment with a signed amount, a flat or percent rate, and what it applies to (the subtotal or one line); Σ amount + shipping_total = total. Documents gain fee_total and payment_terms_detail, the server's structured reading of payment_terms (net days, due on receipt, an early-payment discount).

1.14.0Rivet Finance F2 — the loan lifecycle. Direct financing between verified members: a listing states its ask in loan terms (principal, a fixed fee flat or in bps, grace days); a lender offers at the ask or counters (POST /v1/finance/listings/{id}/offers); the borrower accepts one, echoing the standing authorization's digest (POST /v1/finance/offers/{id}/accept). Acceptance creates three documents on the parties' own connection — an agreement (FIN-), a disbursement the lender pays (DSB-), a repayment the borrower owes (RPY-) — all readable through /v1/documents. When the pledged invoice settles through Rivet, the repayment sweep moves min(proceeds, owed) from the borrower's settlement account to the lender's funding account, same rail; nothing else is ever initiated. New: GET/PUT /v1/finance/setup, /v1/finance/offers, /v1/finance/agreements (+ /repayment, /withdraw); webhook events finance.offer.received and finance.agreement.accepted / funded / repaid / closed / flagged; document types agreement, disbursement, repayment.

1.5.0The provenance family (provenance:read): GET /v1/documents/{id}/history (verified on every read), /lineage (sealed counterparty steps), and /export — a byte-deterministic proof bundle verified OFFLINE with a published script; Rivet-Bundle-Digest is the sha256 of the exact bytes. Document-anchored payments gain POST /v1/documents/{id}/pay (full balance, idempotent across the async settlement gap) and per-key payment_limits set at mint (payment_limit_exceeded names the limit). Webhooks gain payment.settled / payment.failed, and sandbox deliveries are marked sandbox:true.

1.4.0The fiat payment rail over the API. Moving a document into its payment states (payment_scheduled, paid) now executes its payment, gated on the new payments:write scope: simulated in the sandbox, and live once the organization's payment processor is connected (capability_unavailable until then). The transition body gains optional payment_method, source_account_id and scheduled_for.

1.3.0Webhooks — register signed endpoints and receive document.created / document.status_changed / document.edited, each projected for your organization; at-least-once with retries, replay and rotation. Documents gain an updated_since polling filter and a cross-type phase filter, plus a signed-download attachments endpoint. And an MCP server exposes every operation as Model Context Protocol tools, generated from this spec.

1.2.0Document writes (create drafts, edit them, issue, transition — Idempotency-Key required on every write, per-line tax, conflicts answer with the legal set) and the sandbox (a provisioned practice pair with a demo counterparty). Key prefixes now follow the organization — sandbox keys are rk_test_, live keys rk_live_, hard-isolated; keys minted before this rule need re-minting. New error codes: conflict, idempotency_conflict, sandbox_isolation, sandbox_quota. Upcoming event names are reserved in the spec for future delivery.

1.1.0Added GET /v1/enablement — an unauthenticated read of which families this deployment can serve, so a consumer never keeps its own copy of the switch.

1.0.0First release. Read-only documents and payments, org-scoped keys with scopes, cursor pagination, one error envelope, per-key rate limits.