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

# Entities — The Foundation of Every Integration

> What an Entity represents, why it matters, and how it maps to your users.

## Entities — The Foundation of Every Integration

### The Entity Model

An Entity is Method's representation of a person or business in your system — a persistent profile that anchors everything Method knows about your user. Their verified identity, discovered accounts, payment history, and active subscriptions all connect through a single Entity. Every operation your application performs through Method — identity verification, account discovery, payments, monitoring — flows through the user's Entity.

### Why the Entity Model Matters

* **Persistent verification:** Once verified, the Entity carries that status forward. You don't re-verify for every operation.
* **Single reference point:** All accounts, payments, and updates for a user are scoped to their Entity. This also enforces authorization boundaries — one Entity's operations can't affect another.
* **Lifecycle management:** The Entity's status tracks the user's journey from onboarding through active use to potential deactivation, enforcing appropriate constraints at each stage.

### Entity vs End User

Your application has users; Method has Entities. These map one-to-one. Each end user in your application corresponds to exactly one Entity in Method, and that relationship persists throughout the user's lifecycle. You'll typically store the Method Entity ID alongside your internal user ID so you can bridge between the two systems seamlessly.

<Warning>
  Method does not automatically deduplicate Entities. If your application
  creates two Entities for the same person, both will exist independently
  with separate accounts and data. Your application should enforce uniqueness
  (typically by phone number) before creating new Entities.
</Warning>

### Individual vs Corporation Entities

Method supports two types of Entities, corresponding to the two types of financial actors:

<Tabs>
  <Tab title="Individual">
    Individual Entities represent people. To create one, you provide identifying information,  typically at minimum a name and phone number, with additional fields (date of birth, address, SSN) required for identity verification and access to downstream products. Individual Entities are by far the most common type and support the full range of Method's products.

    ```bash theme={null}
    curl https://production.methodfi.com/entities \
      -X POST \
      -H "Method-Version: 2025-12-01" \
      -H "Authorization: Bearer sk_WyZEWVfTcH7GqmPzUPk65Vjc" \
      -H "Content-Type: application/json" \
      -d '{
        "type": "individual",
        "individual": {
          "first_name": "John",
          "last_name": "Doe",
          "phone": "+15121234567"
        }
      }'
    ```
  </Tab>

  <Tab title="Corporation">
    Corporation Entity represents any business, regardless of its legal structure. Corporation Entities go through a business-specific verification process (KYB) and have their own product eligibility path.

    Corporation Entities support a different subset of capabilities than Individuals. They are primarily used for payment origination scenarios and do not have the same product catalog (no credit scores, Connect, or individual-specific features). If your use case involves both consumers and businesses, your architecture will need to account for this difference.

    ```bash theme={null}
    curl https://production.methodfi.com/entities \
      -X POST \
      -H "Method-Version: 2025-12-01" \
      -H "Authorization: Bearer sk_WyZEWVfTcH7GqmPzUPk65Vjc" \
      -H "Content-Type: application/json" \
      -d '{
        "type": "corporation",
        "corporation": {
          "name": "Acme Inc.",
          "ein": "123456789"
        }
      }'
    ```
  </Tab>
</Tabs>

### What Information Do You Need to Collect?

At minimum, most teams need a user's **name and phone number** to create an Individual Entity. However, additional PII (date of birth, SSN or last 4 of SSN, email, address) is typically required to complete identity verification and unlock products like Connect and Credit Score.

Your specific PII requirements are configured during onboarding. A common pattern is to create the Entity early with minimal information, then progressively update it as you collect more data during your onboarding flow. Contact your Method CSM if you're unsure about your team's requirements.

<CardGroup cols={2}>
  <Card title="Entity Lifecycle" icon="arrows-spin" href="/guides/entities/lifecycle">
    Understand Entity states and how users transition from onboarding to active use.
  </Card>

  <Card title="Errors & Edge Cases" icon="triangle-exclamation" href="/guides/entities/errors">
    What can go wrong during Entity creation and how to design around it.
  </Card>

  <Card title="Identity Verification" icon="shield-check" href="/guides/identity-verification/overview">
    The next step after Entity creation — verifying your user's identity.
  </Card>

  <Card title="Entity API Reference" icon="code" href="/reference/entities/overview">
    Full Entity object schema, CRUD endpoints, and field details.
  </Card>
</CardGroup>
