Three units, not one
Integration catalogues are usually quoted as one number. That number can mean apps, API endpoints, pre-built actions or anything with a logo. You cannot compare two vendors, or judge whether your own stack is covered, until you know which one you are reading.
The OCNORA catalogue keeps three units apart, and the integrations page prints each with its own definition:
- Providers (1,075). A provider is one cataloged connection target with its own page: an app, an AI vendor, a database or a single cloud service. This is the number behind the headline.
- Node types (7,621). Every node type with a published contract and a reference page. Of those, 7,378 sit under a provider as operations or triggers. The rest are core node types — control flow, data, AI, files, vectors — that need no connection and belong to no provider.
- Triggers. Node types that start a run. They are included in the node-type count, not added to it, and the integrations page prints how many there are.
A provider is not an app count and not a node count. Read the three together and you get a fairer picture than any one of them gives alone.
Operations and triggers
An operation is a step a run performs: send a message, read a row, create a channel. A trigger is the step that starts a run: an event arrives, a row changes, a schedule fires. Both are node types, and each has a schema that sets its typed inputs, the fields it requires and the shape of what it emits.
That schema is why each node type gets a reference page and a form generated from it, and why Workflow Health can check a saved workflow against it before anything runs. A provider can have many operations and no trigger of its own. In that case a run starts from a core trigger — manual, schedule, webhook, form, chat or another workflow — and the provider’s operations do the work.
How cloud services are counted
Amazon Web Services, Google Cloud and Microsoft Azure are not counted as three providers. Each individual service is cataloged as a provider of its own, with its own page and its own operations. That is a large share of the 1,075 providers, and the integrations page breaks it down cloud by cloud. The rest are apps, AI vendors, databases and developer tools.
Counting per service is how the cloud consoles themselves are organised, and it is how you would search for one: you look for the storage service or the queue service, not for “AWS”. It also inflates the headline next to a catalogue that counts each cloud once, so compare like with like. If your stack is mostly SaaS, subtract the cloud services before you draw a conclusion.
Three providers, read the way the catalogue lists them
Here is a concrete example, taken from the catalogue data the site publishes. The identifiers are node types; the lists are samples, not complete.
provider slack
trigger trigger.slack_event
operations slack.add_pin, slack.add_reaction, slack.create_channel,
slack.delete_message, slack.get_channel_history, …
connection a Slack bot token, selected on each node
provider google-sheets
trigger trigger.google_sheets_row
operations google_sheets.append, google_sheets.read,
google_sheets.update, google_sheets.create_spreadsheet, …
provider openai
typed nodes none of its own
used by ai.agent, ai.classify, ai.extract, ai.generate, ai.llm, …Slack and Google Sheets each count once as providers, whatever the length of their operation lists. OpenAI also counts once, even though it has no typed nodes of its own. Every provider page states how many operations and triggers it has, groups the operations by what they do to your data, and links each one to its reference page. Open the Slack page to see the full list rather than the sample above.
Generic nodes that use a connection
The OpenAI line above is the case that confuses people. Some providers are reached through generic nodes rather than their own. The AI nodes accept a connection to any of the model vendors that support them, and the node picks the provider from the connection you select. The same agent node works with OpenAI or Anthropic; you change the connection, not the node.
A connection is a stored credential. You add it once, and every node that accepts that provider can use it: a provider’s own operations, the generic nodes that list it, and the HTTP node. Where a provider offers a connection test, the credential can be checked when you add it. Where it does not, the first real run is the first check, which is worth knowing before you schedule anything.
Catalogue version, prerequisites and limits
Every figure in this post is read from the catalogue at build time, not typed by hand. The site syncs it from the product’s own public catalogue, and the integrations page prints the catalogue version and its refresh date beside the counts. Check that date before you quote a figure from this post: when the catalogue is refreshed, the numbers here move with it.
- Prerequisites: an account with the provider, a credential with the scopes the operation needs, and a connection in OCNORA that stores it.
- A listed operation means a typed node with a published contract. It does not promise that your account, plan or permissions on the provider’s side allow that call.
- An endpoint with no typed node is not out of reach: call it from the HTTP node with the same connection, or describe the step to the AI builder, which asks our team for a typed node when one is missing.
- The counts describe what the catalogue ships. They say nothing about how often a call succeeds against a given provider; that depends on the provider, your data and your credentials.
The practical test is short. Search the integrations catalogue for the operations your workflow needs, not the brand names, and start from a template where one fits. If the answer depends on a provider you cannot find, or on an endpoint you want to see working, book a demo and bring the list.