cursor/limit → next_cursor), money fields (integer cents), and error envelopes. Each recipe shows the same workflow in three forms: a one-line curl, a Python snippet, and a TypeScript snippet using built-in fetch with inline types.
The host in every example is https://api.montereyfinancial.app. Replace mk_your_key_here with your real key.
Daily incremental sync
Pull yesterday’s new transactions into your warehouse. Anchor on theeffective_at date range, paginate with cursor/limit, dedupe on transaction_id in your warehouse rather than tracking a high-water mark on the API side. Re-running the same window is safe — the API returns the same transaction IDs.
Reconcile a payment to your books
This is the most concrete use ofexternal_contract_number. Two directions:
You see a payment in Monterey, want to find the matching record in your system. Fetch the account by ID, read external_contract_number, look up in your DB.
You have a contract number in your system, want all Monterey transactions for it. List accounts filtered by your contract number (via list-and-filter, since there’s no ?external_contract_number= query parameter today), then list transactions per matching account.
Drill from organization → account → transaction
The resource-composition pattern. Useful for customer service tools and “everything about this customer” views. Three hops: pick an organization, list its accounts, then list a specific account’s transactions. For org-wide aggregates (total payments this month across all accounts), the Reports family is usually a better fit than walking the resource tree — the server-side aggregation is cheaper than fetching every row.Backfill historical data at scale
Walk a multi-year date range in monthly chunks. The pagination pattern is identical to the daily sync — just scaled up. Three operational notes:- Chunk by month, not year. Keeps individual jobs short enough to retry without losing too much state.
- Save
next_cursorbetween chunks. A multi-hour backfill that crashes shouldn’t restart from scratch — store the cursor in your job state and resume. - Respect the limit ceiling. The maximum
limitis 1000; passing higher returns 422 (see Conventions).
Set up autopay on an account
The first write-surface recipe: attach a recurring payment schedule to an account. Two calls — find an eligible stored payment method, then create the schedule.GET /accounts/{id}/payment-methods returns exactly the methods that can fund autopay for that account: they belong to a borrower on the account, and only active methods are included (deactivated ones appear only in the top-level /payment-methods list). No filtering needed on your side.
The example pins a monthly charge to the 1st using anchor_day. For cadences like “every two weeks,” use frequency_unit: "week" with frequency_interval: 2 and no anchor.
- Updating a schedule can change the payment method, amount, end date, or pause state. Cadence and
start_dateare fixed — cancel and recreate to change them. - Removing a payment method that an active or paused schedule still uses returns
409— cancel the schedule first. - One-time payments (
POST /payments) share this shape — account, payment method, amount — but aren’t live yet; every request returns501until submission ships.
Choosing reports vs resource endpoints
The Reporting API surface has two answer shapes — pre-shaped Reports and composable resource endpoints. They cover the same underlying data; the right choice depends on the shape of your question.
Heuristics:
- If the question is a row-shaped business answer (“payments”, “returns”, “balances”), there’s probably a report for it.
- If the question is about a specific entity (“this account”, “this person”), use the resource endpoints.
- If the question is “everything about X”, drill from the resource endpoint.
- When in doubt, reports are less code — they pre-filter on the server, so you write less pagination code on your side.