Stand Guidebook
Chapter 11 of 12
Field guide
What to learn in this chapter
Import one REST API contract at team level, expose a small set of safe operations, attach the integration to a selected Stand-in, and verify live reads or confirmed writes without placing credentials in the model.
Need an exact capability definition, plan requirement, or limitation? Browse the Feature Reference.
Product model
Separate the shared connection from Stand-in access.
An integration is a team-shared connection. Any active member of a Business organization can configure it in the Integrations section of the Stand-ins page. Agree who maintains its URL, credentials, and operation set: editing this shared connection affects every attached Stand-in.
Stand-in access is separate. Open a Stand-in → Edit → 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.
Create
Import an OpenAPI declaration.
For this exercise, use a test endpoint you control that accepts GET /events?limit=2 and returns public event names as JSON. Call it with your usual API client first and save the response so you have something concrete to compare.
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. For an endpoint at https://YOUR-HOST.example/api/events, the base URL is https://YOUR-HOST.example/api and the declaration path is /events. Replace the illustrative host with your real public test host; Stand does not import the declaration’s servers setting.
Paste the OpenAPI JSON or YAML, or upload the declaration file. Preview tools before saving. Importing a declaration describes an API you already operate; it does not create that API. Stand does not automatically expose every imported operation.
OpenAPI documentation
Learn the OpenAPI format.
The OpenAPI Initiative’s official guide explains how to describe paths, operations, parameters, request bodies, and reusable schemas. Stand’s Feature Reference defines the subset this connector supports.
OpenAPI setup checklist
- Use a public HTTPS base URL. Unauthenticated HTTP is accepted, but authenticated integrations require HTTPS. Private networks, internal hostnames, and localhost are not supported.
- Choose no authentication, bearer token, API key header, or basic authentication. Tokens, API keys, and passwords must contain at least eight characters. Basic-authentication usernames and passwords cannot contain control characters.
- Keep secrets in the authentication fields; do not paste them into the OpenAPI description.
- Click Preview tools and select only the operations this integration needs.
- Review Read versus Write for every selected operation.
- Create the integration, then expand its row to verify the URL, auth mode, and tools.
- Use Edit to change metadata or credentials. Re-enter the secret when changing the base URL or authentication settings. Re-import a declaration only when replacing the selected tools.
Small read-only OpenAPI example
openapi: 3.1.0
info:
title: Public events
version: "1.0"
paths:
/events:
get:
operationId: listUpcomingEvents
summary: List upcoming public events
parameters:
- in: query
name: limit
schema:
type: integer
minimum: 1
maximum: 50
responses:
"200":
description: Upcoming public events
content:
application/json:
schema:
type: array
items:
type: object
required: [name]
properties:
name:
type: string
example:
- name: Installation workshop
- name: Customer Q&AThis illustrative contract assumes your endpoint returns an array such as [{"name":"Installation workshop"}]. Adapt the response to your API and configure its base URL separately. Stand does not validate a live response against this response schema.
Operation review
Prefer a small, readable tool set.
For the first exercise, select only listUpcomingEvents and keep it Read. Give every tool a clear operationId, summary, and parameter description so the Stand-in has enough context to choose it.
Review whether an operation changes anything, regardless of its name. GET, HEAD, and OPTIONS start as Read but can be marked Write if they have side effects. POST, PUT, PATCH, and DELETE remain Write and require confirmation.
Preview checks whether Stand can represent the operation as a tool. Unsupported required inputs reject the import; unsupported optional inputs can be omitted. Compare the preview with the API’s real requirements before saving.
Detailed compatibility
Check the supported OpenAPI subset.
The reference covers serialization, schema combinations, request limits, and runtime behavior when adapting a larger existing API.
Stand-in access
Attach the integration from Skills.
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 “What are the next two public events?” Use the test service configured above; the dashboard test does not simulate or undo API calls.
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.
Practice
Try this next
- 01Preview and save only GET /events from the example, then attach it to one test Stand-in.
- 02Ask for the next two public events and inspect the API’s request log for GET /events with limit=2. A claim by the Stand-in that it checked is not sufficient evidence.
- 03Compare the reply with the endpoint’s current response. Change a test event name, restart the test, and verify the new value appears without changing the prompt or knowledge base.
- 04Make the test endpoint temporarily return an error. Confirm the Stand-in reports the problem rather than presenting an invented event list as live data.
- 05Detach the integration and save. Start a fresh test and verify that no new API request is made. The Stand-in may still know general event information from its other sources.
Security and limits
Stand keeps the network boundary narrow.
Stand calls public HTTP or HTTPS services; authenticated integrations require HTTPS. Private networks, localhost, internal hostnames, and redirects are not supported. If an API is internal, this connector cannot reach it simply because a Stand-in has its description.
Authentication belongs in Stand’s credential fields. Stand stores those credentials separately, adds them to the outbound request, and excludes them from the model’s tool schema. The destination API necessarily receives the credential and inputs, so use a host your organization trusts and a credential limited to the intended operations.
Calls are synchronous and have an eight-second total deadline. Return a small textual response, preferably the few JSON fields needed to answer. Do not design the first integration around file downloads, compressed responses, or a long-running job that needs callbacks.
Stand does not automatically resend a Write request after a transport failure. Arrange an API-side way to check whether an action completed before anyone retries it. Read-only GET, HEAD, and OPTIONS calls may try another validated server address within the same deadline.
Runtime reference
Review request, response, and tool limits.
Check the current limits before adapting a large declaration or response. The reference also explains credential handling, confirmed writes, removal, and downgrade behavior.
Troubleshooting
Test the contract before changing the prompt.
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.
Common failures
What to check
- Host rejected
- Use a public HTTP or HTTPS hostname and, when specified, a port from 1 through 65535. Localhost, private networks, metadata hosts, and internal DNS suffixes are blocked.
- Preview has no tools
- Confirm the declaration has a paths object with HTTP operations and that local references resolve.
- Authentication fails
- Verify the auth mode, API key header name, username, and secret. Secrets are entered separately from the declaration and must contain at least eight characters.
- Stand-in does not call the API
- Confirm Use integrations is enabled, the correct instance is checked, and the operation summary clearly matches the question.
- Write does not run
- The visitor must send a later message containing exactly confirm or confirmed.
- Response is unavailable
- The service may have timed out, returned a binary or compressed body, exceeded the response cap, redirected, or hit the per-integration rate limit.
Questions
Common reader notes
Do I need to run an MCP server for a REST API?
No. This beta imports an OpenAPI declaration for an existing REST API. It does not require you to run an MCP server.
Can every rep create an integration?
Any active member of a Business organization can create and edit shared integrations. Agree who maintains each connection, because its changes affect every Stand-in using it.
Can the model see my API token?
The model is not given the configured token. Stand decrypts and injects it only while making the outbound request and redacts direct or commonly encoded echoes from the result. Configure only trusted API hosts because that host necessarily receives the token.