Skip to main content

​
Entity Lifecycle — From Creation to Active Use

​
Lifecycle States

Every Entity in Method exists in one of three states, and understanding these states helps you design the right user experience at each stage of your onboarding flow:
  • Incomplete: The Entity has been created in Method, but the user hasn’t completed all required steps to unlock the platform’s capabilities. This is the starting state for every new Entity. In practical terms, your application knows who this person is, but Method hasn’t yet verified their identity or connected their accounts. Most products are unavailable in this state. Your application should guide the user through the remaining setup steps (typically identity verification) and clearly indicate that setup isn’t finished.
  • Active: The Entity is fully set up and ready for use. Identity verification is complete, and the full range of eligible products is available. This is the steady state for most of your users. Your application can connect accounts, request updates, initiate payments, and enable monitoring. The user should experience the full value of your product.
  • Disabled: The Entity has been deactivated and can no longer be used for new operations. This may happen because your team withdrew consent via the Consent endpoint, because Method disabled the Entity for compliance reasons, or because the user requested account closure through your application. No new operations can be initiated, but existing data, accounts, payment history, updates — remains accessible for reference and reporting.

​
Common Lifecycle Transitions

incomplete → active Triggered when the Entity completes all verification requirements configured for your team. For most teams, this means both phone and identity verification. The transition happens automatically — once the final verification session succeeds, the Entity’s status updates and products become available. active → disabled Can be triggered by:
  • Your team withdrawing consent via the Consent endpoint
  • A compliance event (e.g., a payment reversal triggers a policy review)
  • Method disabling the Entity for policy reasons
This transition is permanent — disabled Entities cannot be reactivated. To re-onboard the user, create a new Entity. What about abandoned onboarding? Entities that stay in incomplete (the user never finished verification) don’t expire. Build a resume flow that picks up where the user left off rather than creating a new Entity on their next visit. Entities must be active before they can be disabled. An incomplete Entity that’s no longer needed can simply be left in place — it doesn’t incur cost or require cleanup.

​
Reacting to State Changes

Entity state changes trigger entity.update webhooks. Subscribe to these to react in real time — for example, unlocking features when an Entity transitions to active, or displaying a deactivation notice when it becomes disabled. See Webhooks.

​
Designing Around Lifecycle States

Your user experiences should reflect the Entity’s state:
  • For incomplete Entities, show a clear onboarding progress indicator. Let the user know what steps remain (e.g., “Verify your identity to see your accounts”). Avoid showing empty states that suggest the product is broken — the user is mid-setup, not experiencing an error.
  • For active Entities, provide full access to your product’s features. This is your core experience.
  • For disabled Entities, display a clear, non-alarming message explaining that the account is no longer active. Allow the user to view historical data if appropriate, but prevent any actions that would fail (payment initiation, account connection, etc.)

Errors & Edge Cases

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

Entity API Reference

See the full Entity object including status, verification, products, and subscriptions.