Connect Stand-ins to live backend systems.

An integration is a team-shared connection. Its name, base URL, authentication, and selected API operations are configured once in the Integrations section of the Stand-ins page.

Stand-in access is separate. Open a Stand-in, choose Skills, enable Use integrations, and select the integration instances that Stand-in may use. Two integrations can use the same provider and still expose different accounts, calendars, base URLs, or operations.

On the Stand-ins page, find Integrations and click New integration. Choose OpenAPI, enter a team-facing name and description, and set the exact public base URL Stand should call.

Paste the OpenAPI JSON or YAML, or upload the declaration file. Preview tools before saving. Stand does not automatically expose every imported operation.

Operation names, summaries, descriptions, parameters, and request-body schemas become the Stand-in tool contract. Clear operationId and summary values help the Stand-in choose correctly.

Stand sends JSON request bodies and preserves declared application/json or vendor +json media types. Query arrays retain Swagger collectionFormat and OpenAPI style/explode serialization for repeated, comma-, space-, and pipe-delimited values.

Operation-level parameters replace matching path-item parameters, including Swagger body parameters and their schema and required state.

Path and header parameters must be scalar. Query parameters may be scalar or arrays of scalar values. Stand rejects required cookie, form, content-based, object, nested-array, and reserved-header parameters that it cannot serialize or safely configure; unsupported optional parameters are omitted from the tool contract.

Path and header parameters use OpenAPI simple serialization. Required parameters using other styles are rejected during import; unsupported optional parameters are omitted.

Stand accounts for numeric bounds when checking required path and query sizes. Required declared headers are checked together against the outbound header limit, so operations that cannot produce a sendable request are rejected during import.

Input schemas must resolve to a concrete type supported by Gemini function calling. Stand applies sibling bounds together with every supported anyOf branch and rejects required schemas that have no valid serializable input. Required unconstrained schemas such as an empty schema object are rejected during import; optional unconstrained parameters and request bodies are omitted.

JSON object keys remain required even when they are governed by additionalProperties instead of being listed under properties.

GET, HEAD, and OPTIONS operations start as Read and can be made Write when an apparently read-shaped endpoint has side effects. Other HTTP methods always remain Write so confirmation cannot be bypassed by configuration.

Stand may try another validated DNS address for a failed read-only GET, HEAD, or OPTIONS request. It never automatically resends a Write tool after a transport failure because the API may already have completed the action.

Open the Stand-in row, click Edit, and choose Skills. Turn on Use integrations and check the team integration instances this Stand-in may use. Save the Stand-in, then use Try it out with a question that requires live data.

The model receives only normalized tools from integrations attached to that Stand-in. Removing the integration from the Stand-in or deleting the team integration refreshes active Stand-in sessions.

OpenAPI declarations and API responses are treated as untrusted data. Stand resolves bounded local reference chains, including schema aliases, and rejects remote, cyclic, or excessively deep references. Imports have liberal limits for document size, schema depth, operation count, and descriptions.

Stand resolves the configured host to public addresses and pins each outbound connection to a validated address. Configuration checks bound DNS resolution to five seconds; runtime resolution shares the eight-second call deadline. Redirects are not followed. Private, loopback, link-local, metadata, and internal hostnames are blocked at configuration and execution time.

Credentials are encrypted in a separate database table and injected only into outbound headers. Authentication secrets must contain at least eight characters so echoed credentials can be redacted without destroying ordinary response text. They are not included in model tools; when the declaration includes the configured API-key header, Stand satisfies it from the stored credential instead of asking the model or visitor. Stand redacts direct and commonly encoded credential echoes from tool results. Inputs are checked against the imported schema, calls are rate-limited, requests and responses are bounded, and external tool names, descriptions, schemas, and output are labeled as untrusted data for the model.

Self-hosted environments must configure STANDCHAT_INTEGRATIONS_CREDENTIAL_KEY as a Base64-encoded 32-byte key. The same key encrypts credentials and signs visitor write confirmations. Without it, Stand permits only public read-only integration tools.

Configure only API hosts your team trusts. The selected host necessarily receives its credential and operation inputs; a generic connector cannot prevent that host from transforming or forwarding data it legitimately receives. Stand requires the secret again before an authenticated integration can change its base URL or authentication metadata, and validates the resulting authentication header together with every selected or retained tool before save.

Start with the integration configuration and one direct Try it out question. The error category usually identifies whether the contract, network boundary, authentication, Stand-in attachment, or confirmation step needs attention.