Skip to main content
The Argyle API uses HTTPS, HTTP basic authentication, REST-style resources, and JSON request and response bodies. Start with the API Reference overview to choose the endpoint family for your implementation.

​
API keys

Create separate Sandbox and Production API keys in Console. The API key secret is shown only when the key is created and is partially obscured afterward. Copy it immediately and store it securely.

​
Authentication

Use HTTP basic authentication on every request:
  • Username: api_key_id
  • Password: api_key_secret
API keys must match the requested environment. Sandbox keys used against Production, or Production keys used against Sandbox, return 401 Unauthorized.

​
Environments

Both Link and the API support Sandbox and Production. Most endpoints are available in both environments. Billing resources such as receipts are Production-only. See Sandbox Testing for sample users, refresh simulation, data updates, and error scenarios.

​
Data readiness

Connected-account data arrives and updates in stages. Do not treat account creation as confirmation that every historical resource is available. Follow Data Delivery and Readiness for account and resource webhooks. Verification implementations should use verification status instead.

​
Compatibility

Implementations must tolerate new optional fields, response fields, enum values, and webhook events. Breaking changes include:
  • Changing authentication or authorization requirements.
  • Removing or renaming an endpoint or webhook.
  • Removing or renaming a required request parameter.
  • Adding a required request parameter.
  • Removing or renaming a response field.
  • Changing a field, request parameter, or query parameter type.
Non-breaking changes include:
  • Adding an endpoint or webhook.
  • Adding an optional request parameter or response field.
  • Returning new response or enum values.
  • Changing an error message.
  • Correcting an HTTP status code that was previously wrong.
Subscribe to the Changelog for API changes.

​
Security

  • Call the Argyle API only from server-side applications.
  • Never include API keys in browser or mobile application code.
  • Store secrets outside source control.
  • Use separate keys for separate backend systems and environments.
  • Delete unused keys.
See Data Security for broader implementation guidance.

​
Status codes

​
Error responses

General request errors return a detail value:
Field validation errors return the affected fields:

​
Null and empty values

Responses can contain partial records.
  • A field can be null when the source does not support it or has no value for the user.
  • An array can be empty: [].
  • An object can be empty: {}.
  • An object can contain properties whose values are all null.
Do not assume a field is present only because its Item reports that field as supported.

​
Pagination

List endpoints return paginated responses. The default limit is 10 and the maximum is 200.
Follow the complete URL returned in next or previous. Do not construct cursor values or request pages in parallel.

​
Rate limiting

The API allows 50 requests per second. Requests above the limit return 429 Too Many Requests. Queue rate-limited requests and retry them after reducing request volume. Avoid immediate retry loops.

​
Concurrency and caching

Limit simultaneous requests when retrieving large result sets. This reduces duplicate work and rate limiting. The Argyle API does not use HTTP caching. If your application caches API responses, manage cache freshness within your own systems.

​
System status

Operational status and incidents are published at status.argyle.com.