> ## 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.
# Platform Fundamentals
> Environments, authentication, data flow patterns, and webhooks.
## Environments
Method provides three isolated environments, each serving a distinct purpose in your integration lifecycle:
Mocked responses. No real institutions contacted, no payments processed.
Simulated flows with test data. Mimics real account discovery, payment timelines, and error states.
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.
```bash theme={null}
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](/reference/versioning) in the API Reference for details.
See the [Authentication](/reference/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.
```bash theme={null}
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"}'
```
Subscription-based access means Method continuously monitors for changes and delivers new data to you automatically. For example, you might subscribe to balance updates for all of a user's accounts, and Method will notify you whenever new data is available, whether that's daily, weekly, or whenever the financial institution reports. Subscriptions are best for keeping dashboards current, triggering automated workflows, and monitoring for changes without requiring user action.
```bash theme={null}
curl https://production.methodfi.com/accounts/acc_yVf3mkzbhz9tj/subscriptions \
-X POST \
-H "Authorization: Bearer sk_WyZEWVfTcH7GqmPzUPk65Vjc" \
-H "Method-Version: 2025-12-01" \
-H "Content-Type: application/json" \
-d '{"type": "update"}'
```
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:
| Event | Description |
| --------------------- | --------------------------------------- |
| `payment.update` | A payment's status has changed |
| `account.create` | A new account was discovered or created |
| `connect.completed` | Account discovery finished |
| `update.completed` | Fresh account data is available |
| `credit_score.update` | A credit score has changed |
See the [Webhooks](/reference/webhooks/overview) reference for setup instructions and the [Events](/reference/events/overview) 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](/reference/idempotency).
* **Rate limits:** Requests are rate-limited to maintain platform stability, and operations can be safely retried without unintended side effects. See [Rate Limiting](/reference/rate-limiting) in the API Reference for details.
* **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](/reference/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.
API keys, headers, and request setup.