Skip to main content

​
Environments

Method provides three isolated environments, each serving a distinct purpose in your integration lifecycle:

Development

Mocked responses. No real institutions contacted, no payments processed.

Sandbox

Simulated flows with test data. Mimics real account discovery, payment timelines, and error states.

Production

Live environment. Real institutions, real data, real money.
Each environment uses separate API credentials and data does not cross environments. This allows you to test safely in Development and Sandbox without affecting Production users or data.

​
Authentication and API Keys

Method uses API keys for authentication. Include your key in the Authorization header of every request. Each environment under each team has its own unique API key. 
curl https://production.methodfi.com/entities \
  -H "Authorization: Bearer sk_WyZEWVfTcH7GqmPzUPk65Vjc" \
  -H "Method-Version: 2025-12-01"
The Method-Version header pins your requests to a specific API version, ensuring your integration behaves consistently even as Method’s API evolves. When a new version is released, you can migrate on your own timeline. If the header is omitted, your team’s default version is used. See Versioning in the API Reference for details. See the Authentication reference for details.

​
How Data Flows: On-Demand vs Subscriptions

Method offers two complementary models for accessing data, and understanding when to use each is important for designing your product experience.
On-demand access means you request data when you need it. For example, when a user opens their dashboard, you might request a fresh balance update for their accounts at that moment. On-demand is best for user-initiated actions, one-time data pulls, or situations where you need specific data at a specific time.
curl https://production.methodfi.com/accounts/acc_yVf3mkzbhz9tj/updates \
  -X POST \
  -H "Authorization: Bearer sk_WyZEWVfTcH7GqmPzUPk65Vjc" \
  -H "Method-Version: 2025-12-01" \
  -H "Content-Type: application/json" \
  -d '{"type": "direct"}'
Not all products support both modes. Refer to each product’s documentation for availability.

​
Real-Time Notifications via Webhook Events

Method’s platform is fundamentally asynchronous, when you request an account update or initiate a payment, the result isn’t always available immediately. Instead, Method notifies your system when something happens through webhook events: real-time HTTP notifications sent to an endpoint you configure. For your product team, the key implication is this: your application should be designed around event-driven updates rather than polling or refresh buttons. When a payment posts, when new account data is available, when a user’s credit score changes, Method tells you. This event-driven model enables responsive, real-time user experiences without the complexity and cost of constant polling. The typical webhook handling pattern looks like this:
  1. Method sends an HTTP POST to your configured endpoint with event details
  2. Your backend acknowledges receipt (return a 2xx response promptly)
  3. Your backend fetches the updated resource using the IDs in the event payload
  4. Your application updates its local state and, if needed, refreshes the user’s UI
This pattern applies to virtually every webhook: payment status changes, new account data, completed discovery, credit score updates, and more.
Return your 2xx response before processing the event. If your endpoint takes too long to respond, Method will retry the delivery, which can cause duplicate processing.
Nearly every product creates and updates events, so webhooks are the primary mechanism for keeping your system in sync with Method. Common webhook events include:
EventDescription
payment.updateA payment’s status has changed
account.createA new account was discovered or created
connect.completedAccount discovery finished
update.completedFresh account data is available
credit_score.updateA credit score has changed
See the Webhooks reference for setup instructions and the Events reference for the full list of event types.

​
Reliability and Safety

Method’s platform includes built-in mechanisms to ensure reliability. Your engineering team will handle implementation details, but at a product level the key guarantees are:
  • Idempotency keys: Duplicate operations are prevented automatically (so a network hiccup doesn’t create two payments). See Idempotency.
  • Rate limits: Requests are rate-limited to maintain platform stability, and operations can be safely retried without unintended side effects.
  • Versioned APIs: Method maintains versioned APIs so integrations remain stable as the platform evolves. New capabilities are introduced without breaking existing implementations.
  • Paginated list endpoints: All list endpoints return paginated results, ensuring predictable performance regardless of data volume. See Pagination in the API Reference for details.
  • Reliable updates: Changes to liabilities and payments are delivered through subscriptions and webhooks, ensuring your application stays in sync with real account activity.
These aren’t features you need to design around, they’re guardrails Method provides out of the box.

Authentication Reference

API keys, headers, and request setup.