The Rivet API reads everything and, where the environment has writes enabled, writes documents too. It answers with the same documents and payment rollups your team already sees in the app, projected for your organization — never for the counterparty. Four steps get you from nothing to a page of documents.
1. Create an account
There is no separate developer account. A key acts as your organization, so it belongs to the organization your team already works in. Sign up the normal way; if your company is already on Rivet, ask an admin instead.
2. Mint a key
An organization admin opens Settings → Developers, names the key and picks its scopes. The secret appears once, on creation. Admins can also mint a key with their session token:
curl -X POST "https://test.rivetx.app/v1/keys" \
-H "Authorization: Bearer rk_live_…"rk_live_, a sandbox organization’s with rk_test_. The two are hard-isolated — a key presented against the other kind of organization is refused with sandbox_isolation.3. Your first request
Send the key as a bearer token. The key is your organization, so there is no organization id to pass and no way to ask for someone else’s data.
curl "https://test.rivetx.app/v1/documents?type=invoice" \
-H "Authorization: Bearer rk_live_…"Every response carries Rivet-Api-Version — the spec version it was produced under — and authenticated calls carry the rate-limit headers.
4. Read the whole list
Lists come back newest first with a next_cursor. Pass it back as cursor until it returns null:
curl "https://test.rivetx.app/v1/documents" \
-H "Authorization: Bearer rk_live_…"Where to go next
- The document model — read this before you map anything. One record, two sides.
- Authentication — scopes, rotation, revocation.
- Errors — one envelope, a closed set of codes.