Change & response policies - Docs

Faraday was built by engineers for engineers. Here you'll find the commitments we're making about system changes, including API and data changes, as well as the response times you can expect from the platform.

If you have questions about these policies, or want more information on upcoming changes, please reach out to your Faraday account representative or contact support.

Last updated: 17 October 2025

API changes

This policy outlines our commitment to maintaining backward compatibility and communicating any changes responsibly.

Non-breaking changes

We may introduce non-breaking changes at any time, including:

Adding new optional request parameters
Adding new fields to responses
Introducing new endpoints
Expanding accepted input ranges or formats
Improving performance or stability
Adding new enum values (where clients should tolerate unknown values)

We encourage integrators to build defensively—for example, by ignoring unknown response fields.

Breaking changes

We will not make breaking changes to the Faraday API without a deliberate, versioned release (see Versioning below). Specifically, once an API endpoint or field is published, documented, and used by any client, we will ensure that:

Existing endpoints will continue to function as documented.
Existing request and response fields will not be removed or renamed.
Field types and semantics will remain consistent.
Authentication and authorization mechanisms will remain compatible.

In short: if your integration works today, it will continue to work tomorrow.

Versioning

If we ever need to make a breaking change, it will be introduced under a new, versioned API namespace (e.g., /v2/), and the prior version will remain available and supported for a defined deprecation period. Details on version lifecycles and upgrade guidance will be announced in advance.

Deprecations

If we need to deprecate functionality, we will:

Announce the deprecation publicly (via changelog, email, or dashboard notification).
Provide a minimum of 6 months’ notice before removing any deprecated functionality.
Offer migration support and documentation to help you adapt.

Exceptions

If a change is required urgently to address a security, privacy, or data integrity issue, Faraday may implement it sooner than the standard notice period. In such cases, we will communicate the change and its justification as promptly as possible.

Communication

Changes will generally be documented in our Changelog and reflected in our API documentation.

Breaking changes will be communicated via email to all clients.

Data changes

This policy describes how Faraday manages changes to the structure and semantics of the consumer data we make available to clients. Its goal is to ensure stability and predictability for clients who depend on consistent data schemas and meanings over time.

Non-breaking changes

We may introduce non-breaking changes at any time, including:

Addition of new fields or attributes
Introduction of new categories or values within existing categorical fields, provided they do not change existing meanings
Improvements to data coverage, accuracy, or timeliness
Updates to records that do not alter the meaning or structure of existing fields

Notification: None required, though such changes may be documented in release notes or data updates.

Breaking changes

These include:

Removal or renaming of fields
Changes to data types (e.g., integer → string)
Redefinition of categories or meanings (e.g., redefining an income_range bucket)
Structural changes to file formats or schemas

Policy: Faraday will provide at least 30 days’ advance notice before implementing any breaking change.

Notification will include:

A description of the change and its rationale
The expected date of deployment
Guidance for adapting to the new schema

When possible, Faraday will:

Offer a 30-day transition period during which both old and new structures are available
Provide mapping documentation or versioned schema references

Exceptions

If a change is required urgently to address a compliance, privacy, or data integrity issue, Faraday may implement it sooner than the standard notice period. In such cases, we will communicate the change and its justification as promptly as possible.

Communication

All change notices will be shared through Faraday’s standard communication channels, which may include:

Direct email notifications
In-platform notifications
Updates to the Faraday documentation

Response times

Faraday operates on a commercially reasonable best effort basis. We do not promise scheduled deliveries or guaranteed timeframes for data processing unless you have a specific agreement with Faraday.

Typical performance

While we don't guarantee specific schedules unless you have a specific agreement with Faraday, here's what our clients typically experience:

Lookup API: 500ms response time, 100 requests per second
Configuration API: 500ms response time, 8 requests per second
File upload and download: Usually processed within 24 hours
Database connection: Usually processed within 72 hours

When guaranteed schedules matter

We understand that some clients have critical business processes that require guaranteed data delivery schedules. In these cases, please discuss your specific needs with your account team.

Our commitment to you

While we can't guarantee specific delivery times, we are committed to:

Transparent communication about processing status
Proactive notification of processing issues
Continuous improvement of our processing efficiency
Working with you to find solutions that meet your business needs

Need guaranteed schedules?

If your business requires guaranteed data delivery schedules, please contact us. We can discuss custom solutions and pricing for dedicated scheduling services.

Contact our team to discuss your specific requirements and explore how we can work together to meet your needs.