Every sample on every page follows this. Change it any time.

Get a test key
BashBrainTeammatesPricingDevelopersGet a test key

connect

Let a user connect their apps, such as Gmail, Slack and Notion, so Bash can work in them. A connect link signs one user in to one app from the catalog. Once they agree, Bash can use that app in their work.

Connect an app for your company

Your company's own Bash will use it, so open the link yourself.

TypeScript
const sheets = await vestra.connect('google-sheets');console.log(sheets.url);

List their apps

You also get the catalog they may pick from.

TypeScript
const apps = await traveller.connect.list();const catalog = await vestra.connect.catalog({ search: 'calendar' });console.log(apps.data.length, catalog.data.length);

Disconnect an app

TypeScript
await traveller.connect.remove('con_7hs');

Connect an app for your company

Your company's own Bash will use it, so open the link yourself.

Python
print(vestra.connect("google-sheets").url)

List their apps

You also get the catalog they may pick from.

Python
apps = traveller.connect.list()catalog = vestra.connect.catalog(search="calendar")print(len(apps.data), len(catalog.data))

Disconnect an app

Python
traveller.connect.remove("con_7hs")

List their apps

You can also list every app they may connect.

CLI
vestra connect --user traveller-42vestra connect --catalog --search calendar

Disconnect an app

CLI
vestra connect --remove con_7hs --user traveller-42

List their apps

You can also list the catalog your users may pick from.

HTTP
curl "$VESTRA_BASE_URL/v1/connections?user_id=traveller-42" \  -H "Authorization: Bearer $VESTRA_API_KEY" curl "$VESTRA_BASE_URL/v1/apps?search=calendar" \  -H "Authorization: Bearer $VESTRA_API_KEY"

Disconnect an app

user_id says whose connection it is.

HTTP
curl -X DELETE "$VESTRA_BASE_URL/v1/connections/con_7hs?user_id=traveller-42" \  -H "Authorization: Bearer $VESTRA_API_KEY"
MCP
{  "method": "tools/call",  "params": {    "name": "connect",    "arguments": { "user": "traveller-42", "app": "gmail" }  }}

Good to know

When Bash needs an app during a job

If Bash needs an app during a job, it sends an interaction of type connect: a request that waits for an answer. Send your user its link, or answer { approve: false } to decline.

After the user agrees

Once your user agrees, they are sent to your return_url, or to your company's first allowed return URL. Your webhooks receive connection.completed or connection.failed, so you know how it went.

Which apps users can connect

GET /v1/apps lists the apps your users may connect, with your company's allowlist applied.

The routes behind connect6 routes, each with every field in the API reference
GET/v1/appsThe apps your users may connect, after your allowlist.Key scope: runtime (or all)
POST/v1/connectionsGet a connect link for one app, for one user (user_id) or the company's own Bash. After consent the user lands on your return_url (or your first allowed one, or our own page), and a webhook fires. The link carries the id of the connection it makes.Key scope: runtime (or all)
GET/v1/connectionsThe connected apps of one user (user_id), or of the company's own Bash.Key scope: runtime (or all)
GET/v1/connections/{connection_id}One connection's status. user_id names whose it is.Key scope: runtime (or all)
DELETE/v1/connections/{connection_id}Disconnect. user_id names whose it is.Key scope: runtime (or all)
GET/v1/connect/returnHosted by us. The app sends the user here after consent; we record it and forward them to your return_url. You never call it.