> ## Documentation Index
> Fetch the complete documentation index at: https://docs.montereyfinancial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Domain concepts

> How organizations, people, borrower roles, accounts, transactions, payment methods, and autopay schedules fit together.

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

```mermaid theme={null}
erDiagram
    ORGANIZATION ||--o{ ACCOUNT : owns
    PERSON }o--o{ ACCOUNT : borrows
    PERSON ||--o{ PAYMENT_METHOD : stores
    ACCOUNT ||--o{ TRANSACTION : has
    ACCOUNT ||--o{ AUTOPAY_SCHEDULE : schedules
    PAYMENT_METHOD ||--o{ AUTOPAY_SCHEDULE : funds

    ORGANIZATION {
        string id
        string display_name
        string legal_name
    }

    PERSON {
        string id
        string display_name
        date date_of_birth
        string ssn_last_four
        string primary_phone
        string primary_email
    }

    ACCOUNT {
        string id
        string organization_id
        string external_id
        string external_contract_id
        int current_balance_cents
        string status_code
    }

    TRANSACTION {
        string transaction_id
        string account_id
        string organization_id
        string type
        int amount_cents
        date effective_at
    }
```

## 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](https://docs.montereyfinancial.com/api-reference/persons/get-a-person.md) 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](https://docs.montereyfinancial.com/api-reference/accounts/get-an-account.md) 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](https://docs.montereyfinancial.com/api-reference/payment-methods/get-a-payment-method.md) 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](https://docs.montereyfinancial.com/api-reference/external_api.openapi.json) 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](https://docs.montereyfinancial.com/api-reference/conventions.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.