Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.montereyfinancial.dev/llms.txt

Use this file to discover all available pages before exploring further.

Every Reporting API request must carry an Authorization: Bearer <key> header. The key resolves to a set of organization IDs the request is allowed to see; absence of authorization or a key that resolves to no orgs is rejected with 401.

​
The Bearer header

GET /reports/crr?from=2024-01-01&to=2024-12-31 HTTP/1.1
Host: api.montereyfinancial.app
Authorization: Bearer mk_your_key_here
The same shape works from any HTTP client: 
curl -H "Authorization: Bearer mk_your_key_here" \
  "https://api.montereyfinancial.app/reports/crr?from=2024-01-01&to=2024-12-31"

​
Organization scoping

When the portal mints a key, an operator picks a set of organization IDs the key is allowed to see. Two patterns are common:
  • All-of-customer: one key covers every organization record a customer has registered with Monterey.
  • Subset: a key sees only the orgs a particular team within the customer is responsible for.
The server enforces this on every account- and transaction-shaped query — there is no path through the API that returns a row from an organization outside the allowlist.

​
401 vs 403

The Reporting API uses two distinct status codes:
StatusWhenBody
401 UnauthorizedMissing / malformed / unknown / revoked / expired key{"detail": {"error_code": "missing_token" | "invalid_token"}}
403 Forbidden?organization_id=X where X is not in the key’s allowlist{"detail": {"error_code": "organization_out_of_scope"}}
An empty result is not the same as 403. If you query for a date range with no matching rows, you’ll get 200 with {"rows": []}. A 403 means the query itself targeted an organization you can’t see.

​
Rotating a key

Treat the key like a password. When you need to rotate:
  1. Mint a new key in the portal — choose the same organization allowlist.
  2. Update your integration to use the new key.
  3. Revoke the old key in the portal. Revoked keys begin returning 401 immediately.
There is no overlap window required — the new key starts working as soon as the portal commits the row, and the old key keeps working until you revoke it.

​
What we log

For every request we log the key prefix (the first 8 characters of the original API key, stored alongside the hash) and the resolved organization IDs. We never log the full API key, and the hash is one-way — losing your copy of the key means it cannot be recovered.