Skip to main content

​
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.
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.

​
Individual vs Corporation Entities

Method supports two types of Entities, corresponding to the two types of financial actors:
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.
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"
    }
  }'

​
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.

Entity Lifecycle

Understand Entity states and how users transition from onboarding to active use.

Errors & Edge Cases

What can go wrong during Entity creation and how to design around it.

Identity Verification

The next step after Entity creation — verifying your user’s identity.

Entity API Reference

Full Entity object schema, CRUD endpoints, and field details.