How connections are checked
Every service is checked against its live API before it's listed, and again from time to time. What the check proves, and what it can't.
Operate As is a pass-through: it holds a client's access and attaches it to each call. So what has to be right for every service is how it connects: the address its API lives at, and where the client's key or sign-in goes on each call. Every service is checked for exactly that, against the live service, before it's listed.
What's checked
We can't sign in as your client, but a service still shows whether we'd reach it the right way:
| Check | Passes when |
|---|---|
| The API's address | It answers like an API at our address and asks for credentials (401 or 403, or an error about the key), rather than a docs page, a dead host or 404 everywhere |
| Where the key goes | Sent with an obviously fake key in the place the service expects it, the API answers differently from no key at all, so it read the key we sent |
| Sign-in addresses | The service's own sign-in page answers, and its token address refuses a made-up code rather than not existing |
| Tools | A few of the service's tools are called without credentials and ask for them instead of answering 404 |
| Drafted tools | Each one's path appears on the page of the service's own API documentation it was written from, and the live API doesn't answer it with 404 |
Each service's result and the day it was checked are in the catalog. A service whose check fails isn't listed until it's fixed.
| Result | What it means |
|---|---|
| Verified | The API asked for credentials where we send them, and any sign-in addresses answered as they should |
| Answers | The API answered at our address, but nothing sent without an account shows it checks keys. Common for GraphQL APIs |
| Reachable | The address includes the client's own account, such as their Freshdesk subdomain or Jira site, so only the host could be reached |
| Account | The address is entirely the client's own, such as their Salesforce instance, so only the sign-in could be checked |
Where services come from
| Source | How it's used |
|---|---|
| Written by us | The first services, with their sign-ins tested end to end |
| Activepieces (MIT) | Read for how each service signs in or which key it takes, its API's address, and the header that carries access. Only what checks out live is kept |
| APIs.guru (CC0) and providers' own descriptions | Published OpenAPI descriptions, for addresses, how keys and sign-ins work, and tools |
| Drafted from documentation | For services that publish no description, written from their API documentation, with every path checked as above |
What a check can't prove
A check runs without any client's access, so it can't call the API as a real account. It can't show that a particular permission is enough for a particular call, or that a tool's inputs are exactly what the service wants today. Those surface on the first real call as the service's own error, returned to you unchanged in status and data.
A service that signs in with OAuth also needs our app registered with that service before clients can connect it. Until then it's listed as coming soon.
If a connection doesn't behave as described, tell us: the fix is usually one line in that service's file, and it's checked again before it ships.