Connectors

Named HTTP client configurations with typed operations. Executed in-process in the backend (no container overhead). Operations are exposed as agent tools. Auth resolved from the Secrets store at call time. Endpoints:

POST   /api/v1/connectors                                        # Create connector
GET    /api/v1/connectors                                        # List connectors
GET    /api/v1/connectors/{namespace}/{name}                     # Get connector
PUT    /api/v1/connectors/{namespace}/{name}                     # Update connector
DELETE /api/v1/connectors/{namespace}/{name}                     # Delete connector
POST   /api/v1/connectors/parse-openapi                          # Parse OpenAPI spec (no connector required)
POST   /api/v1/connectors/{namespace}/{name}/import-openapi      # Import operations from OpenAPI spec into connector
POST   /api/v1/connectors/{namespace}/{name}/test/{operation}    # Test an operation
POST   /api/v1/connectors/{namespace}/{name}/oauth/authorize     # Begin per-user OAuth flow (returns provider URL)
GET    /api/v1/connectors/{namespace}/{name}/oauth/status        # Current user's OAuth connection status
DELETE /api/v1/connectors/{namespace}/{name}/oauth/token         # Disconnect (delete the user's stored token)

Auth types: bearer, basic, api_key, oauth2_client_credentials, oauth2_authorization_code, sinas_token (forwards caller’s JWT), none Auth is resolved from the Secrets store. Private secrets override shared for the calling user — enabling multi-tenant patterns where each user can have their own API key for the same connector. An api_key can be sent as a header (default; header names it, default X-Api-Key) or as a query parameter (position: query + paramName, default api_key). Importing an OpenAPI spec also reads its securitySchemes and pre-fills a suggested auth config.

OAuth 2.0

Two grants are supported. In both, secret names the Secret holding the client secret — the secret value itself never lives in connector config. Client credentials (oauth2_client_credentials) — service-to-service. Sinas fetches a token from tokenUrl, caches it in-process until shortly before expiry, and refreshes automatically:

connectors:
  - name: analytics-api
    namespace: default
    baseUrl: https://api.example.com
    auth:
      type: oauth2_client_credentials
      tokenUrl: https://auth.example.com/oauth/token
      clientId: my-client-id
      secret: ANALYTICS_CLIENT_SECRET        # Secret holding the client secret
      scopes: [read:stats]
      clientAuthMethod: body                 # "body" (client_secret_post) or "basic" (client_secret_basic)
      tokenParams: { audience: "https://api.example.com" }   # optional extra token-request params

Authorization code, per user (oauth2_authorization_code) — the connector acts on behalf of the individual user. Each user clicks Connect Account in the console, consents at the provider, and gets their own encrypted token row (PKCE-protected; refreshed automatically on expiry):

    auth:
      type: oauth2_authorization_code
      authorizeUrl: https://provider.example.com/oauth/authorize
      tokenUrl: https://provider.example.com/oauth/token
      clientId: my-client-id
      secret: PROVIDER_CLIENT_SECRET
      scopes: [read:user]

Register this redirect URI with the provider (must match exactly): https://<your-domain>/auth/connectors/oauth/callback If a user has not connected (or their authorization expired with no refresh token), operations fail with an explicit “reconnect” error rather than sending an unauthenticated request. The flow is bound to the initiating browser via an HttpOnly cookie; set OAUTH_BIND_BROWSER_SESSION=false only in split-origin local dev (console and API on different ports). Agent configuration:

agents:
  - name: slack-bot
    enabledConnectors:
      - connector: default/slack-api
        operations: [post_message, get_channel_info]
        parameters:
          post_message:
            channel: "{{ default_channel }}"

YAML config:

connectors:
  - name: slack-api
    namespace: default
    baseUrl: https://slack.com/api
    auth:
      type: bearer
      secret: SLACK_BOT_TOKEN
    operations:
      - name: post_message
        method: POST
        path: /chat.postMessage
        parameters:
          type: object
          properties:
            channel: { type: string }
            text: { type: string }
          required: [channel, text]

Execution history:

GET    /executions                               # List executions (filterable by chat_id, trigger_type, status)
GET    /executions/{execution_id}                # Get execution details (includes tool_call_id link)
POST   /executions/{execution_id}/continue       # Resume a paused execution with user input

Executions include a tool_call_id field linking them to the tool call that triggered them, enabling execution tree visualization in the Logs page. Input schema presets: The function editor includes built-in presets for common input/output schemas. Use the “Load preset” dropdown when editing schemas:

Preset	Use case
Pre-upload filter	Content filtering before file upload (receives file content, returns approved/rejected)
Post-upload	Processing after successful file upload (receives file_id, metadata)
CDC (Change Data Capture)	Processing database changes (receives table, rows, poll_column, count)
Message Hook	Message lifecycle hook (receives message, chat_id, agent; returns content mutation or block)

Getting Started

Platform

Build

Storage

Triggers

Configure

Admin

OAuth 2.0

​OAuth 2.0

OAuth 2.0