Providers

Providers are the services your users can link their accounts from.

Resource model

Each provider is structured as an integration containing one or more resources, each with one or more operations (actions):


Integration (e.g., tmobile)
  └── Resource (e.g., paymentMethod)
        ├── read  — List saved payment methods
        └── write — Add a new payment method

When creating a link, you specify the full path: integrationId + resource + action.

Supported integrations

Integration	Resources	Actions
`tmobile`	`paymentMethod`, `mobileBillingStatement`	`read`, `write`
`att`	`paymentMethod`, `mobileBillingStatement`	`read`, `write`
`verizon`	`paymentMethod`, `mobileBillingStatement`	`read`, `write`
`ubereats`	`orderHistory`	`read`

Fetch the full catalog with argument and result schemas via GET /v1/providers.

Argument validation

Some operations accept arguments (e.g., card details for paymentMethod:write). Arguments are validated against a Zod schema at link creation time. Use the GET /v1/providers discovery endpoint to inspect the JSON Schema for each operation.

Result validation

Each operation defines a canonical result schema. After an automation completes, the result data is validated against its schema before persisting. If validation fails, the link is marked as failed with a RESULT_VALIDATION_ERROR code. The canonical schemas ensure consistent result shapes across providers — for example, all carriers return billing data in the same { billing: BillingStatement[] } format regardless of their native API responses.

Provider automations

Each operation maps to an automation function that:

Navigates to the provider’s login page
Sends commands to fill in form fields
Yields to the user for authentication (password, 2FA)
Waits for post-login conditions
Extracts or writes the account data

Next steps

List Providers API — API reference with full schema details
Building a Worker — Write custom automations