Skip to content

List connectors

GET /connector

The platform catalog — visible to every role, `connector:view` included — plus this organization's own custom connectors, which (unlike connections and toolboxes) are already browseable by every member regardless of any grant: a custom connector's existence, name and category are catalog metadata, not a private resource (`connector:view` is the universal catalog-browse permission; see customConnectorRouter.ts's module doc). There is no `?visibility=org` oversight mode here (removed 2026-09-04): `connector:manage` no longer surfaces per-row attribution for a connector the caller was never explicitly granted access to — `can_manage` on an org-owned row reflects only a real `edit` grant of their own, present on every row regardless of any query parameter. Platform catalog rows omit `can_manage` (no ACL concept). Connectors the caller's restrictions block are RETURNED, flagged `restricted`/`restricted_by`, not filtered out — so a restricted caller's page is the same length as anyone else's. `prev_cursor` is always null here.

Query Parameters

searchstring

Substring match on the connector name/label.

categorystring

Exact category match.

customboolean

Send true to narrow to this organization's own connectors.

Response Body

next_cursorstring,null
prev_cursorstring,null
resultobject[]
access_viastring

How the CALLER reaches this connector — not who else can. owner — they own it. direct — a grant naming them personally. team — a grant to a team they belong to (or, per §6.2, one they administer), named in access_via_team. org — an organization-wide grant. When several sources apply the BROADEST wins and the caller's access level is not consulted: owner, else org, else team, else direct. So a caller granted edit personally AND view org-wide reads org — a narrower grant must never mask org-wide exposure, since this field says how far the connector reaches, not what the caller may do with it. Deliberately NOT gated on can_see_shares, and deliberately not a widening of it: this is the caller's OWN grant and their OWN team memberships, so a view/use grantee receives it while the grantee list — information about colleagues — stays closed to them. No other member is ever named. ABSENT when nothing reaches the caller — a transfer answering the ex-owner of a resource that was never shared, or a catalog row browsed with no grant behind it. Absent means "no source to name", never "not permitted", and never an implied org.

Possible values:
ownerdirectteamorg
access_via_teamobject

Present exactly when access_via is team, absent otherwise. The team the caller reaches this connector through — one of their own teams, never a disclosure about anybody else.

2 properties
idstring

Team id (team_…).

namestring,null

Team display name, or null when the team no longer resolves in the directory — the same null contract every resolved grantee name carries.

byoaboolean

True when the connector needs a customer OAuth app (BYOA) — a placeholder client id, a real id with a placeholder secret, or a real id with no platform OAuth secret stored for it. The first two are derived from the config on the catalog summary, so they are on every row; the third comes from one cached platform-credential read.

can_manageboolean

Present only on org-owned/custom connector rows (omitted for platform catalog rows, which have no ACL concept). Whether the caller may edit this connector's config — a real edit grant of their own. connector:manage alone no longer implies this (removed 2026-09-04): org owners/admins do not manage-by-default a connector nobody explicitly shared with them.

categorystring
customboolean

True for a connector this organization authored or forked.

descriptionstring,null
labelstring
logostring,null
ownerstring

Catalog owner. Org-owned values mark this org's custom connectors.

owner_user_idstring,null

Always null. Unlike a connection or toolbox, a custom connector has no durable per-user owner — only resource_acl grants (the creator receives an ordinary, revocable edit grant at creation time, the same as anyone shared with later; see customConnectorRouter.ts's module doc). Kept for shape parity with the other two resources' summaries.

restrictedboolean

True when the caller's restrictions block this whole connector. A blocked connector is LISTED and flagged, never omitted — a picker that only got "no match" could not tell "your admin blocked it" from "that provider does not exist". It still cannot be connected: POST /connection and GET /connector/{slug}/tools refuse it.

restricted_bystring,null

Which precedence layer the winning rule came from, or null when nothing blocks this connector. Adds which to restricted's whether and nothing else — no rule id, author, reason or coverage. Same field and same meaning as on GET /connector/{slug} and on a connection row.

Possible values:
roleusernull
slugstring

Stable connector key — this is the identifier everywhere, not an id.

curl -X GET 'https://api.elaichi.ai/connector' \
  -H 'Authorization: Bearer $ELAICHI_API_TOKEN' \
  -H 'Content-Type: application/json'
const response = await fetch('https://api.elaichi.ai/connector', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer ' + process.env.ELAICHI_API_TOKEN,
    'Content-Type': 'application/json',
  },
});

const data = await response.json();
console.log(data);
import os
import requests

url = "https://api.elaichi.ai/connector"
headers = {
    "Authorization": f"Bearer {os.environ['ELAICHI_API_TOKEN']}",
    "Content-Type": "application/json",
}

response = requests.get(url, headers=headers)
print(response.json())