Directory coming Month 3 · EU residency tracking
SaaS Products with API Access
sourc.dev tracks SaaS products that expose a programmatic API as a primary interface. Payments, authentication, email delivery, analytics, storage, communication, and monitoring — every category where developers integrate directly against an API rather than clicking through a dashboard. Each product entry tracks pricing tiers, EU data residency, uptime SLAs, API rate limits, webhook support, versioning strategy, and plan change history. Every data point has a source URL. Every change is timestamped.
SaaS with API access — the infrastructure layer
There is a meaningful distinction between a SaaS product and a SaaS product with API access. Salesforce is SaaS — you log in, you click, you manage pipelines. Stripe is also SaaS, but the API is the product. You never need to open the Stripe dashboard to process a payment. The dashboard exists as a reporting layer on top of the API, not the other way around.
This distinction was formalized when Stripe launched in 2011 with seven lines of code to accept a credit card payment. No procurement process. No sales call. Integrate, test, deploy. Twilio did the same for communications in 2008 — an API call to send an SMS. Supabase followed for databases, offering a Postgres backend accessible entirely through a REST and GraphQL API.
sourc.dev treats API-first SaaS as infrastructure. A pricing change at Stripe is an infrastructure event, not a marketing update. When Twilio raises per-message rates, it affects cost models across thousands of production applications. When Supabase changes row limits on its free tier, side projects either stay or migrate. These are infrastructure decisions with downstream consequences, and they deserve the same rigour as tracking cloud compute pricing. That is what this directory provides: structured, versioned, source-linked data on the SaaS products that developers build on top of.
The EU residency split
The European cloud infrastructure market is dominated by US hyperscalers. AWS holds approximately 35% of the EU market, Microsoft Azure approximately 25%, and Google Cloud Platform approximately 15%, according to Synergy Research Group (Q3 2025). That leaves roughly 25% for EU-native and other providers. This concentration creates a compliance exposure that is growing more acute, not less.
The Schrems II ruling in July 2020 invalidated the EU-US Privacy Shield. The EU-US Data Privacy Framework, adopted in July 2023, partially restored legal transfer mechanisms, but it faces its own legal challenges and does not eliminate the need for due diligence. Cumulative GDPR fines have exceeded €4.5 billion as of early 2026. EU public procurement requirements increasingly mandate EU data residency as a qualification criterion, particularly in Germany, France, and the Nordic countries.
The result is a growing market for EU-native alternatives across every major SaaS category. sourc.dev tracks residency status for each product:
| Category | US-based | EU-based / EU-hostable |
|---|---|---|
| Payments | Stripe (US) | Adyen (NL), Mollie (NL) |
| Auth | Auth0 (US) | Supabase (EU-hostable), Ory (DE) |
| SendGrid (US) | Resend (EU-hostable), Brevo (FR) | |
| Analytics | Google Analytics (US) | Plausible (EU), Fathom |
| Storage | AWS S3 (US) | Cloudflare R2 (edge), Scaleway (FR) |
This is not an exhaustive list. It is a representative sample of the split that sourc.dev tracks at the product level. Every entity listing will include a residency field — US, EU, EU-hostable, or multi-region — verified against the provider's own documentation. For a deeper explanation of how EU data residency affects technical and procurement decisions, see the EU data residency guide.
The API-first architecture
Stripe proved in 2011 that developer experience is a competitive moat. Before Stripe, accepting online payments required merchant accounts, payment gateway contracts, PCI compliance audits, and months of integration work. Stripe reduced that to an API key and a function call. The entire payments industry restructured around this insight: if the developer integration is good enough, the product sells itself.
Twilio applied the same principle to communications. Before Twilio, adding SMS or voice to an application meant negotiating with carriers, managing phone number inventory, and handling protocol-level complexity. After Twilio, it was an HTTP POST request. Supabase did it for databases — a managed Postgres instance with auto-generated REST and GraphQL APIs, authentication, storage, and realtime subscriptions, all accessible without writing SQL or configuring servers.
These products are infrastructure components now, not software subscriptions. When a team evaluates Stripe versus Adyen, or Supabase versus Firebase, they are making an infrastructure decision that will persist for years. Switching payment processors mid-growth is a multi-quarter engineering project. Migrating authentication providers affects every user session. These decisions deserve structured data — pricing tiers, rate limits, versioning policies, uptime records, residency status — not marketing pages. That is the gap sourc.dev fills. SaaS products with AI features powered by language models will also track which models are integrated and how automated decisions are disclosed under the EU AI Act.
Entity listings launching Month 3. EU residency tracking is a priority attribute.
Browse language models — available now.
Frequently asked questions
What makes a SaaS product "API-first"?
An API-first SaaS product is designed so that the API is the primary interface, not a secondary add-on. Stripe is the canonical example: launched in 2011, its entire product was seven lines of code to process a payment. The dashboard came later. API-first means the programmatic interface receives the most engineering investment, the best documentation, and the fastest updates. Products like Twilio, Supabase, and Plausible follow this pattern — developers integrate directly against the API, and the web interface is a convenience layer on top.
What is the difference between REST and GraphQL APIs?
REST (Representational State Transfer) uses fixed URL endpoints, each returning a predefined data structure. GET /users/123 returns user 123, always the same shape. GraphQL, introduced by Facebook in 2015, uses a single endpoint where the client specifies exactly which fields it wants. REST is simpler to cache and debug. GraphQL reduces over-fetching — you never receive data you did not request. Stripe, Adyen, and most payment processors use REST. Shopify and GitHub offer GraphQL. Neither is objectively superior; the choice depends on data complexity and client diversity.
What is EU data residency and why does it matter for SaaS?
EU data residency means that personal data is stored and processed within the European Union or European Economic Area. Under GDPR, transferring personal data to countries without adequate data protection (including the US, post-Schrems II ruling in 2020) requires additional safeguards such as Standard Contractual Clauses. For SaaS products, this affects where servers are located, where backups are stored, and where support staff can access data. Cumulative GDPR fines have exceeded €4.5 billion as of early 2026, with Meta alone receiving a €1.2 billion fine in 2023 for US data transfers.
Beyond GDPR, why would I choose EU-based SaaS?
Three practical reasons beyond legal compliance. First, latency: if your users are in Europe, EU-hosted infrastructure is physically closer, reducing round-trip times by 80-120ms compared to US East Coast servers. Second, procurement: public sector contracts in Germany, France, and the Nordics increasingly require EU data residency as a mandatory criterion, not a preference. Third, operational independence: US-based SaaS products are subject to US jurisdiction, including CLOUD Act subpoenas and OFAC sanctions enforcement, which can affect EU customers without notice.
What are webhooks and why do they matter?
A webhook is an HTTP callback — when an event occurs in one system, it sends an HTTP POST request to a URL you specify. Instead of polling an API every 30 seconds to check if a payment succeeded, Stripe sends your server a webhook the moment the payment completes. Webhooks reduce API calls, lower latency, and enable event-driven architecture. Reliability matters: Stripe retries failed webhooks for up to 72 hours. Adyen retries for 24 hours. sourc.dev tracks webhook reliability, retry policies, and event types for each SaaS product.
What is API rate limiting?
API rate limiting restricts how many requests a client can make within a time window. Stripe allows 100 requests per second in live mode. Twilio allows 100 requests per second for most endpoints. SendGrid allows up to 10,000 emails per second on dedicated IPs. Rate limits exist to protect shared infrastructure, ensure fair usage, and prevent abuse. Exceeding the limit returns an HTTP 429 status code. sourc.dev tracks rate limits per plan tier — a critical factor when evaluating SaaS products for high-volume use cases.
How large is the EU-native SaaS alternatives market?
The EU cloud market was valued at approximately €15 billion in 2025, with US hyperscalers (AWS, Azure, GCP) holding roughly 75% market share. EU-native SaaS is a growing subset. Adyen (Netherlands) processed €970 billion in payment volume in 2024. Mollie (Netherlands) serves 200,000+ businesses. Brevo (France, formerly Sendinblue) has 500,000+ customers. Plausible Analytics (EU) tracks 1 million+ websites. The EU Cloud Code of Conduct and Gaia-X initiative are accelerating adoption of EU-native alternatives, particularly in regulated sectors.
When should I build vs buy a SaaS component?
Build when the component is your core differentiator — if payments are your product, do not use Stripe. Buy when the component is infrastructure you need but do not compete on. A 2024 analysis by Andreessen Horowitz estimated that building a Stripe-equivalent payment system in-house requires 15-25 engineers and 18+ months. Auth0 estimates that a custom authentication system takes 6-8 months for a mid-size team. The calculation changes at scale: Uber built its own mapping stack after spending $58 million annually on Google Maps API. For most companies under 500 employees, buying is the rational default.
What is API versioning and why should I care?
API versioning is how a SaaS provider manages breaking changes. Stripe uses date-based versioning (e.g., 2024-12-18) — your integration stays pinned to the version you started with, and you upgrade on your schedule. Twilio uses major versions in the URL path (/v2/). Some providers (notably early-stage startups) do not version at all, meaning any API change can break your integration without warning. sourc.dev tracks versioning strategy, deprecation policies, and minimum supported version age for each SaaS product.
When did API-first SaaS become a category?
The category emerged between 2008 and 2012. Twilio launched in 2008 with an API for sending SMS — no dashboard, no UI, just an API. Stripe launched in 2011 with seven lines of code to accept a payment. SendGrid (2009) did the same for email delivery. By 2015, Bessemer Venture Partners formally defined "API-first" as a SaaS subcategory in their State of the Cloud report. The approach proved that developer experience could be a primary competitive moat, not just a feature.
What does "five nines" uptime actually mean?
Five nines (99.999%) uptime allows 5 minutes and 15 seconds of downtime per year. Four nines (99.99%) allows 52 minutes and 36 seconds. Three nines (99.9%) allows 8 hours and 46 minutes. Most SaaS products advertise 99.9% or 99.95% in their SLA. Stripe's API had 99.999% uptime in 2024 according to their status page. Adyen reports 99.99%. sourc.dev tracks actual uptime against SLA commitments, because the number in the contract and the number in production are often different.
How does the EU AI Act affect SaaS products with AI features?
The EU AI Act, which entered into force in August 2024 with phased enforcement through 2026, classifies AI systems by risk level. SaaS products that embed AI features powered by language models — such as automated decision-making in CRM, AI-powered analytics, or language model integrations — may fall under "limited risk" or "high risk" categories depending on their use case. High-risk systems require conformity assessments, human oversight, and detailed technical documentation. SaaS products offering AI features to EU customers need to disclose which models they use and how automated decisions are made. sourc.dev tracks which SaaS products include AI features and which language models power them.
How big is the global SaaS market?
Gartner estimated the global SaaS market at $232 billion in 2024, growing at 17% annually. By that measure, it will exceed $270 billion in 2025. The API-first segment — SaaS products where the API is the primary interface — represents an estimated $40-50 billion of that total, based on revenues from Stripe ($18B+ revenue run rate), Twilio ($4B), Adyen ($1.8B), and hundreds of smaller providers. The average mid-size company uses 130 SaaS products (Productiv, 2024). Enterprise companies average 371.
How do I avoid vendor lock-in with SaaS APIs?
Four strategies reduce lock-in risk. First, use an abstraction layer: libraries like LiteLLM (for language models) or payment orchestration platforms let you swap providers without rewriting integration code. Second, own your data exports: ensure the SaaS product supports full data export in standard formats (CSV, JSON, SQL dump) at any time, not just during offboarding. Third, avoid proprietary query languages or SDK-only access — prefer standard REST APIs with well-documented schemas. Fourth, track contract terms: auto-renewal clauses, data deletion timelines post-cancellation, and API access during migration periods. sourc.dev documents data portability and export capabilities for every tracked product.