Skip to main content
Beta — in development. Intent is not generally available. The request, response, and event values below preview the planned API and may change before release. Contact your Method CSM to confirm availability before integrating.
Intent is designed to reduce latency and increase data freshness for eligible users. Send an Intent when a user reaches a milestone that indicates they are likely to enter your Entity creation flow. You do not need to create an Entity first. If Method finds a match from the user’s identifying information, it can begin preparing eligible liability data in the background, reducing the time the user will need to wait later in the flow.

When to Call Intent

When Intent is enabled for your team, mirror the meaningful journey events you already track in your product analytics. Send an Intent for each enabled event as it happens. Include your external_user_id and session_id in context, and campaign details in metadata, to connect the event to your funnel. For example, send an Intent when you issue a prescreened offer and another when the user visits your site. Common journey points include:
  • You send the user a prescreened or prequalified offer
  • The user visits your site
  • The user signs up or signs in
  • The user becomes eligible for an offer
  • The user starts an application
  • The user adds an item to a cart
  • The user begins checkout
Earlier signals give Method more time to prepare eligible data. Each additional signal can trigger another eligibility and freshness evaluation, but does not guarantee another data pull. Method owns the event catalog and provides the event values enabled for your team. Use metadata for customer-specific context.

How It Works

1

Send the journey event

Send the predefined event and the user’s available identifying information in identity.individual. Include at least one individual field. Add optional session and source information in context.
2

Method stores and matches the Intent

Method stores the Intent and acknowledges receipt without waiting for background work. It then compares the submitted identity to individual identity records across Method’s network. The response does not disclose whether a match occurred.
3

Method evaluates eligible work

If Method finds a matching individual, it evaluates liability eligibility and data freshness, then starts eligible updates in the background. If Method does not find a match, it stores the Intent but does not prepare data for that event.
4

Continue the normal Method flow

Continue Entity creation, consent, Connect, and product requests as usual. Method handles identity matching internally. You do not need to pass an Intent ID during Entity creation. If eligible updates have finished, Method can reuse the prepared data. If work is still running, the normal Update flow completes when it is ready.

Example Request

The planned initial release accepts identity.individual. Support for sending an existing identity.entity_id is planned for a later release. This illustrative request sends a journey event before Entity creation:
Confirm availability and the enabled event catalog with Method before using this example. Send Intent only from your server. Use the same Idempotency-Key when retrying the same request, and use a new key for each different request. See Idempotency.

Request Fields

  • event: A predefined Method event. Example values include user_sign_up, user_log_in, commerce.add_to_cart, and lending.user_prequalified.
  • identity.individual: The user’s available identifying information. Individual fields are optional, but at least one must be supplied. Fields include first_name, last_name, email, phone, dob, address, and ssn. Method matches against identity data already in Method’s network, not only Entities created by your team.
  • context (optional): Predefined correlation and request-context fields:
    • external_user_id: Your identifier for the user.
    • session_id: Your identifier for the user session.
    • source: The channel where the event occurred, such as website, app, email, or chat.
    • client_ip_address: The user’s IP address.
    • client_user_agent: The user’s client or browser identifier.
  • metadata (optional): Free-form fields that provide customer-specific context for the event.

Response

The planned response acknowledges receipt of the Intent. For the request above, the illustrative response is:
The response does not include an entity_id, submitted identity information, or a match result. It confirms receipt only; it does not mean data is ready. Intent does not create an Entity. Background updates run asynchronously, and there is no published completion SLA. Continue the normal Method flow to retrieve data and track readiness.

Behavior and Limits

  • An accepted Intent confirms receipt only. Use Method APIs such as Connect, Updates, and Payments, along with their webhook events, as the source of truth for data availability and status.
  • Intent does not return consumer financial data. Method returns data through its APIs only after you collect the required user consent.
  • Method uses data-freshness thresholds and can reuse eligible cached data instead of starting new work for every Intent.
  • Intent alone does not initiate a new credit report pull.
  • Intent does not enroll an Entity or Account in a Subscription.

Connect

Discover a user’s liabilities and create Accounts.

Updates

Retrieve current data from supported financial institutions.

Card Brand

Retrieve card names, art, and structured card details.
A complete Intent API reference will be published before general availability.