Call a connector through its API
Use the endpoint and contract belonging to the connector.
Your code sends inputs and handles a structured response.
date2026-09-24slotsYour path, in three steps.
- 01
Copy the generated example
In Integrations & Exports, choose cURL, JavaScript or Python. The example matches this connector.
- 02
Supply params
Follow the contract inputs. Send the key through the x-bridge-secret header from your server.
- 03
Handle the result
Read success, data and error. Keep the execution reference to investigate an issue.
Want to go deeper?
Open just the topic you need.
Overview
Two public surfaces, and no others
A deployed connector's own endpoint — documented here — and a Toolset's MCP endpoint. Everything else you may see the dashboard call is internal, unversioned, and will change without notice. Do not build on it.
There is no SDK to install and no OAuth flow. A key in a header, a JSON body, a JSON answer.
The request
curl -X POST "https://api.example.com/api/v1/bridge/{connectorId}/execute" \
-H "x-bridge-secret: {your-connector-secret}" \
-H "Content-Type: application/json" \
-d '{ "params": { "date": "2026-08-21" } }'The exact address and key are on the connector's Integrations & Exports tab, already filled in. Every input goes inside params; a field at the top level is ignored.
The key is also accepted in the query string. Do not use it there.
It exists for no-code tools that cannot set a header. Anything in a URL ends up in browser history, proxy logs and server access logs.
The response
{
"success": true,
"data": { "slots": ["09:00", "10:30"] },
"meta": {
"executionId": "9e600e25-…",
"scriptVersion": 3,
"durationMs": 412,
"timestamp": "2026-08-21T09:12:04.821Z"
},
"needsRepair": false
}{
"success": false,
"data": null,
"error": { "code": "AUTH_ERROR", "message": "the session was refused" },
"meta": { "executionId": "…", "durationMs": 60 },
"needsRepair": false
}The envelope never changes shape. Branch on success. meta.executionId is what to quote in a support request; meta.scriptVersion is what makes an old result explainable.
The four error codes
| Code | Whose problem | What to do |
|---|---|---|
INPUT_ERROR | The caller's | A missing input, or a value the site rejects. The message names it. Retrying unchanged fails identically. |
AUTH_ERROR | The sign-in's | The connector could not act as the signed-in user. Vela may recover on its own; otherwise the account owner gets an email. Never a code problem. |
API_CHANGED | The site's | The target changed. This is what schedules an automatic repair. Also raised when the response no longer matches the declared output. |
EXECUTION_ERROR | Transient | A network failure or a timeout. Back off and retry before treating it as real. |
Limits
| Limit | Value | On exceeding |
|---|---|---|
| Per connector | 1 request per 5 seconds, refilling a burst of 3 | 429, with Retry-After and the seconds to wait in the message |
| Concurrent, per account | 5 executions at once | 429. Nothing is queued — the call is refused and has to be made again |
| Executions, per month | Paid plan: 10,000 per used connector, not pooled. Trial: 10,000 in total. | Refused at the applicable limit unless paid overage is enabled |
Progress for slow connectors
Adding /stream to the same path gives server-sent events as the steps complete, then the same envelope as the final event. Same key, same inputs, passed as query parameters.
The contract as OpenAPI
Each connector publishes its own OpenAPI document, downloadable from the Integrations & Exports tab. It is what every other export is generated from, so it can never describe an endpoint that does not exist — point your generator at it rather than transcribing by hand.
The HTTP status of every failure, and what is safe to retry.
↗Your situation doesn’t match the guide?
Talk to the team ↗