Skip to main content
These recipes assume you’ve read Authentication and Conventions — they cover the Bearer header, pagination shape (cursor/limitnext_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 the effective_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 of external_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_cursor between 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 limit is 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.
Operational notes:
  • Updating a schedule can change the payment method, amount, end date, or pause state. Cadence and start_date are 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 returns 501 until 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.