Connectors

Connected has to mean usable, not just authorised.

OAuth succeeding is not an integration. These are the connections where the chain actually completes — authorised, reachable, synchronised, provenanced, and usable by a running workflow.

Chain-verified

Authorised through to a usable outcome

Least-privilege

Scoped to the workflow, not the credential

Provenanced

Every write traces to its triggering event

Introduction

What we mean by a connector being real.

A connector count is one of the least informative numbers in this category. Almost any platform can authorise against almost any provider; what varies enormously is whether the data then arrives, stays current, and is usable by a workflow with its provenance intact.

We treat a connection as operational only when the whole chain completes: authorised, reachable, fetched or synchronised where required, available to the runtime, provenanced, and demonstrably usable in a workflow that produced an outcome.

That standard is why this list is shorter than a catalogue. The pages here describe connections we can state that chain for, rather than every provider an OAuth screen exists for.

Standard
Authorised → usable → outcome
Access model
Least privilege, workflow-scoped
Data location
Source stays authoritative
Deeper guides
Integration guides

Why this exists

Most integration failures happen after the connection succeeds.

The authorisation step is the easy part and the part everyone demonstrates. The failures arrive later: a sync that silently stops, a field mapping that drifts, a duplicate created because matching ran after the create rather than before.

The second failure is scope. Connecting a workspace often grants far more access than the workflow needs, and nobody notices until an audit or an incident.

The third is provenance. When a write cannot be traced back to the event that caused it, an incorrect record cannot be explained or reversed, and trust in the whole dataset degrades faster than any single error would justify.

You're likely here because

  • A connection shows as active and no usable data has arrived
  • Nobody can say which event caused a particular write
  • Credentials grant far more access than the workflow needs

How to choose

Where to look depending on what you need.

If

You want implementation detail for one platform

If

You know both systems and want the handoff pattern

If

You are evaluating whether a connection is governable

If

You want to understand how context attaches at all

How it works

The chain a connection has to complete.

A connection that stops at any stage is not operational, however green the status indicator is.

01Authorised02Reachable03Available04Provenanced05Usable

Step 01

Authorised

Credentials exist and are scoped to the specific records and actions the workflow needs rather than the provider’s full surface.

Step 02

Reachable

The runtime can actually call the provider under those credentials, within the rate limits that apply.

Step 03

Available

Required records are fetched or synchronised and present for the runtime to read at decision time.

Step 04

Provenanced

Every record carries where it came from and when, so a downstream write can be explained after the fact.

Step 05

Usable

A workflow reads it, acts on it, and produces an outcome. This is the only stage that proves the previous four.

Scope

Honest limits on what this list means.

  • Availability depends on provider configuration, scopes, workspace setup, and deployment state — validate before treating a connection as a dependency.
  • A documented connector is not a guarantee that every provider capability is exposed.
  • Rate limits and bulk-path availability are set by the provider, not by us.
  • Connector breadth is deliberately not optimised as a headline number.

FAQ

Questions about this collection.

How many connectors are there?

Deliberately not a headline figure. The number that matters is whether the specific connection your workflow depends on completes the chain from authorised through to a usable outcome, which is what each page here states.

My system is not listed. Can it still connect?

Often yes. This list reflects connections we have written up to the standard above; it is narrower than what is reachable. Describe the workflow and we can be specific.

Does data get copied into UbiVibe?

The source system stays authoritative. The runtime reads live records with provenance rather than maintaining a second copy that drifts.

What access do you need?

Least privilege, scoped to the workflow. A connection made for one job does not acquire access for others.

What happens when a provider changes an API?

The workflow fails visibly with its source context preserved and routes to an exception queue. A silent drop is treated as a defect rather than a degraded mode.

Is connector availability the same for every workspace?

No. It depends on your provider configuration, authentication, scopes, and deployment. Validate the specific connection before depending on it operationally.

Start with ARIA

Ask ARIA about integrations.

You do not have to pick your way through this collection to get started. Describe the outcome you want and ARIA determines which capabilities, systems, and workflows the job needs.

  • ARIA acts only through the systems and permissions you connect.
  • Connections use scoped credentials you can change or revoke.
  • Actions are recorded, and consequential ones can require approval.

Goes to UbiGrowth, with the page you asked from attached. We do not sell or share it. Prefer to talk? Call 972-823-1294.

Start here

Start from the workflow, not the connector list.

Describe the outcome you need. ARIA resolves which systems have to participate and whether the required connection actually completes the chain — which is a better first question than which logos appear on a page.

700+ connections, safely

What ARIA is allowed to do in your connected systems, and who decides.

Connecting your connected systems is a permission decision, not just a setup step. These are the controls that decide what ARIA can reach, what it can change, what gets recorded, and how you take the access back.

Required permissions

ARIA works through the scopes the connection was granted, and no others. Authorization happens at the provider, so the permissions being requested are shown by the system itself before anything is connected.

What it can reach

Reachable systems are the intersection of what your organization approved in the connector registry and what the requesting identity is permitted to use. Identity resolves before execution, not after.

What it can do

Actions run through explicit execution paths with state, spend, and failure boundaries — a bounded worker path rather than an open-ended agent loop with a credential.

Credential handling

Credentials live in the governed connection layer and are resolved through canonical connection identity. They are not pasted into individual workflows, prompts, or generated artifacts.

Action logging

Execution carries state and traces: what triggered the work, which connection it used, and what came back — including an explicit failure when something did not run.

Approval and revocation

Consequential actions can be made to require a person to approve them. Access can be changed or revoked at the connection, and ARIA loses that reach without unpicking the work already completed.