API Provider Directory
Deprecation risk scores, versioning models, and breaking-change histories for 20 providers — sorted by risk.
Anthropic API
ai
date based
event-driven
Undocumented, assumed short
Anthropic's date-based versioning for models can lead to unexpected breaking changes if not monitored closely, as older models are sunset. API features may also be updated without explicit versioning.
View deprecation profile →Datadog API
observability
date based
event-driven
Variable, often short
Datadog API uses a date-based versioning model without explicit versioning in endpoints. Breaking changes can occur with little advance notice, making proactive monitoring crucial.
View deprecation profile →GitHub GraphQL API
devtools
none
event-driven
Varies, often short for breaking changes
The GitHub GraphQL API does not have explicit versioning and relies on clients to adapt to schema changes. Breaking changes can occur with little advance notice, requiring continuous monitoring.
View deprecation profile →GitHub REST API
devtools
date based
event-driven
3-6 months
GitHub's REST API uses date-based versioning for breaking changes, meaning changes can be introduced without strict adherence to semantic versioning. While they provide release notes, developers must actively monitor announcements.
View deprecation profile →Google Ads API
adtech
date based
monthly
3-6 months
The Google Ads API has a monthly release cycle with potential breaking changes. While there's a sunset policy, keeping up with monthly updates and understanding their impact can be challenging.
View deprecation profile →HubSpot API
crm
date based
quarterly
30-90 days
HubSpot uses a date-based versioning model for its API, meaning changes can be introduced on a set schedule, often quarterly. This requires continuous monitoring to avoid breaking changes.
View deprecation profile →Meta Graph API
social
date based
monthly
30-90 days
The Graph API uses date-based versioning with frequent monthly releases. While not all releases contain breaking changes, the rapid cadence and potential for unexpected modifications necessitate careful monitoring.
View deprecation profile →Microsoft Graph API
identity
date based
monthly
90-180 days
Microsoft Graph uses a date-based versioning model for its APIs, with breaking changes often introduced monthly. While long-term support (LTS) versions offer stability, keeping up with the latest updates and their deprecation schedules can be challenging.
View deprecation profile →Salesforce REST API
crm
date based
event-driven
6 months
Salesforce uses a date-based versioning model for its REST API. While not strictly semantic versioning, changes are generally announced with notice, but the event-driven nature can lead to unexpected breaking changes if not closely monitored.
View deprecation profile →Shopify Admin API
ecommerce
date based
event-driven
90-180 days
Shopify's Admin API uses date-based versioning, meaning changes are tied to specific release dates. While they aim for stability, breaking changes can occur with new releases, requiring proactive monitoring.
View deprecation profile →SendGrid API
date based
event-driven
90 days
SendGrid's date-based versioning means older versions are deprecated and eventually sunset, leading to potential breaking changes if not updated. They communicate changes but require proactive migration.
View deprecation profile →Meta Marketing API
adtech
date based
quarterly
90-180 days
The API uses a date-based versioning system with quarterly updates, which can lead to frequent breaking changes if not managed proactively. Deprecations are usually announced with a few months' notice.
View deprecation profile →Okta API
identity
date based
event-driven
90 days
Okta's date-based versioning means changes are tied to specific release dates rather than strict semantic versioning. While they provide notice, the event-driven nature of breaking changes can require proactive monitoring.
View deprecation profile →OpenAI API
ai
date based
event-driven
3-6 months
OpenAI's date-based versioning can lead to unexpected breaking changes if migration windows are tight. While they announce changes, the frequency and impact require proactive monitoring.
View deprecation profile →Plaid API
fintech
date based
quarterly
90 days
Plaid uses a date-based versioning model with quarterly releases, which can lead to frequent breaking changes if not actively managed. While they provide notice, proactive monitoring is essential.
View deprecation profile →Slack API
communications
event driven
event-driven
30-90 days
Slack API introduces breaking changes on an event-driven basis rather than strict versioning. While they provide notice, the lack of predictable versioning increases integration risk.
View deprecation profile →Square API
payments
date based
event-driven
60-90 days
Square uses date-based versioning which can lead to unexpected breaking changes if not actively monitored. While they aim for clear communication, the event-driven nature requires proactive attention from developers.
View deprecation profile →Stripe
payments
date based
monthly
Typically 3-6 months for significant changes
Stripe releases new API versions monthly, often including minor breaking changes that require careful review, though major architectural changes are less frequent.
View deprecation profile →Twilio API
communications
date based
event-driven
90 days
Twilio often updates APIs with new features and sometimes introduces breaking changes without explicit version numbers, requiring careful monitoring of their release notes.
View deprecation profile →Zendesk API
support
date based
quarterly
90 days
Zendesk uses a date-based versioning model with roughly quarterly updates. While they provide notice, migrations can still be disruptive if not managed proactively.
View deprecation profile →Never get blindsided by an API change again
Deprecatr AI monitors 150+ providers, maps changes to your codebase, and delivers migration checklists before your team hits a breaking change.
Join the Waitlist