Skip to main content
The Monterey Client API presents one normalized model across Monterey’s servicing systems. Every record you can access is anchored to an organization in your access token’s allowlist.

​
Data model

​
Organization

An organization represents a client entity serviced by Monterey. You access one or more organization IDs through your API key. Access tokens minted from that key carry the same allowlist. Accounts and transactions include organization_id, so you can group multi-org results without another lookup.

​
Person

A person is usually a borrower on one or more accounts. Use GET /v1/persons to discover people, then fetch person detail when your workflow needs contact or address enrichment. The API never exposes full SSNs, SSN hashes, internal notes, or operator attribution.

​
Account and borrower roles

An account belongs to one organization and can have multiple borrowers. Account responses use one borrowers collection. See account detail for the generated response schema. Known role values include primary, borrower, co_borrower, and co_signer. The set is open. New or unmapped servicing codes may appear as values such as role_7. Do not implement exhaustive switches that reject unknown roles. The primary borrower appears first. is_primary is the stable way to identify that relationship. Account list responses keep borrower data narrow. Fetch account detail when your workflow needs additional borrower identity fields.

​
Transaction

A transaction is a money movement on an account, such as a payment, adjustment, fee, or refund. Each row includes its account and organization IDs. Use GET /v1/transactions across visible accounts or /v1/accounts/{id}/transactions for one account. Add from or to only when you need a date bound.

​
Payment method

A payment method is a stored card, bank account, or wallet belonging to a person. The API returns display-safe metadata and never returns full card or account numbers. See payment method detail for the generated response schema. Payment methods are immutable as instruments. Update display fields, or create a new instrument and deactivate the old one.

​
Card capture

The secure card-capture proxy creates a stored card payment method for a borrower on an account. If you omit party_id, Monterey uses the account’s primary borrower. If you need the card to belong to a different active borrower on the same account, pass that borrower’s party_id explicitly. If the borrower already has a current billing address on file, you can omit both billing-address fields. You can also send billing_address_id for a saved address or billing_address for a one-time address. The inline address is transient; Monterey does not create a saved party address from it.

​
Autopay schedule

An autopay schedule connects an account to a payment method. Its cadence is frequency_interval × frequency_unit. A schedule can be active, paused, cancelled, or expired. Pausing is reversible. Cancellation is not. Cancelled schedules remain visible for audit history.

​
Identifier conventions

Every account includes a Monterey id. Persist it as the durable API key and use it in path parameters and relationships. When present, external_contract_id can join Monterey account data back to the contract in your system. When present, external_id can reconcile the account with source servicing-system exports. Both values are strings, so preserve leading zeros and other source formatting. See the generated OpenAPI contract for the complete account response schema.

​
API surfaces

  • Resource endpoints expose organizations, people, accounts, and transactions.
  • Payment endpoints manage payment methods and autopay schedules.
  • Pre-shaped reports are available through client_dashboard, not this API.
All API surfaces share the authentication, rate-limit, pagination, and error conventions documented in Conventions.