You are sketching a new product on a Saturday morning. It might be a fitness tracker, it might be a small CRM. You have a list of things to wire in before you write a single feature: crash reporting, sign-in, payments, file storage, messaging. You wonder whether you are about to spend a month on plumbing everyone else has already chosen.
A new section on apis.io, called Applications, speaks to exactly that worry. It takes 644 leading apps across 90 categories, from CRM and accounting to period trackers and mobile games, and reads what each one actually integrates with. The evidence comes from the SDKs in its source, the integrations it lists, and the trackers in its Android build. Every integration is joined to a provider in the catalog. The result is 2,911 distinct providers, 92.3% of them already profiled on apis.io.
Each row is graded by how the catalog knows it. A row is observed if it was seen in the app's own code or build. It is declared if it appears on the app's integrations page. It is inferred if it is neither, and inferred rows are never counted.
The first finding is how much of every app is the same app. A shared-layer page ranks providers by how many categories use them. Firebase and Sentry each turn up in 67 of the 90. Stripe is in 57, Facebook in 52, Amazon S3 in 47 and Slack in 46. OpenAI is in 44, and Anthropic is already in 39. The post's point is that crash reporting, sign-in, payments, storage and messaging are not what makes a fitness app different from a CRM. They are the floor both stand on. So the list on your Saturday sketch is not a month of unique work. It is the common layer, and the data shows which names sit in it.
The second finding is about agents. The post says the floor is mostly ready for them, and that the gaps are specific. Nine of the twelve most-shared providers publish a first-party MCP server the catalog could verify. The three that do not are Facebook, Apple and Google sign-in. That is identity and the platforms, the layer every app hands its users to. So if you plan to let an agent act inside your product, the sign-in step is where you should expect friction.
The post is careful about how it counts. Of the 2,697 providers checked so far, 651 have a verified MCP server and 1,445 have confirmed none. Each was checked by hand against its own GitHub org and docs, rather than by trusting what a listing claims.
If you would rather read your category top to bottom, each one is a blueprint. The post uses CRM and Sales Pipeline as its example. It covers eight reference apps, from HubSpot to Twenty, built on 54 providers, every one of them in the catalog. The mean Kin Score is 58.1, and there are 32 verified MCP servers. The page splits the stack into the domain layer that makes it a CRM, the common layer it shares with everything, and the agent layer. Every row links the source it was read from, and each app has its own page too.
The capability names come from the business capability model, now extended for apps. The enterprise model behind Business Capabilities describes what an organisation does, and had nowhere to put food databases, fitness tracking or agent payments. The API Evangelist extension adds 380 capabilities for consumer, B2B and agent products, credited separately from the Turbo EA model it builds on.
The pages are free. The data is on the Understanding plan. The category index is free at /api/v1/applications, and one category's full blueprint, filterable by layer and evidence tier, is at /api/v1/applications/<category>. It is also available to agents as the get_application_blueprint MCP tool.
The post ends by turning the same scrutiny on its own record. If your company appears in a blueprint and the row is wrong, you can tell apis.io through its developer page, and it gets fixed.
What you take away is practical. Before you build the plumbing, look up your category and see which providers the leading apps already stand on. Expect Firebase, Sentry and Stripe near the top. Expect a verified MCP server for most of the shared layer, and expect sign-in to be the exception. And treat any row you rely on as a reading with a grade, observed, declared or inferred, and not as a promise.
Read the original: https://apis.io/2026/11/07/what-90-kinds-of-apps-are-built-on-firebase-and-sentry-sit-under-67-of-them/