Skip to main content
This reference documents every property available in connector YAML files. Each property includes its purpose, allowed values, real-world examples, and whether it affects the UI (Hub, Dashboard), MCP (tool declarations), or both.
Impact Legend:
  • 🖥️ UI - Affects StackOne Hub, Dashboard, or Connect flows
  • 🤖 MCP - Used in MCP tool declarations (list tools)
  • ⚙️ Runtime - Affects API request execution

File Structure

Connectors use a modular file structure:
Partial files keep connectors maintainable by splitting actions into logical groups. The main connector file handles authentication and metadata, while partials contain resource-specific actions.How it works: The CLI merges all partials into a single connector definition during stackone push. The $ref syntax tells the merger which partials to include. File naming must follow the pattern {provider}.{resource}.s1.partial.yaml for auto-discovery.Example from BambooHR:
  • bamboohr.connector.s1.yaml - Auth config
  • bamboohr.employees.s1.partial.yaml - Employee actions
  • bamboohr.timeoff.s1.partial.yaml - Time-off actions

Root Properties

StackOne

Impact: ⚙️ Runtime The schema version for the connector file format.
The version determines which parser and validator the runtime uses. Currently only 1.0.0 is supported. Future versions may introduce new properties or change behavior. Always use 1.0.0 for new connectors.

info Section

Metadata about the connector displayed in the UI and used for identification.

info.title

Impact: 🖥️ UI Human-readable provider name displayed in the Hub and Dashboard.
The title appears in:
  • Integration Hub provider list
  • Dashboard connector cards
  • Account connection screens
  • Logs and audit trails
Use the official product name with proper capitalization (e.g., “BambooHR” not “Bamboo HR” or “bamboohr”).

info.key

Impact: 🖥️ UI | 🤖 MCP | ⚙️ Runtime Unique identifier for the connector. Used in API calls, MCP tool names, and internal routing.
The key is the primary identifier:MCP: Prefixes all action IDs → bamboohr_list_employeesAPI: Used in account connections:
Runtime: Routes requests to correct connector configuration.Warning: Changing a key after deployment breaks all existing linked accounts and API integrations.
When forking an existing StackOne connector, you can customize the connector name (info.title). However, if you want to inherit future StackOne updates to that connector, the info.key field must match the StackOne connector key.Example: If you fork StackOne’s BambooHR connector:
  • ✅ You can change info.title to “Custom BambooHR”
  • ⚠️ Keep info.key: bamboohr to receive future updates from StackOne
  • ❌ Changing info.key to custom_bamboohr prevents automatic update inheritance
Recommendation: When forking existing StackOne connectors, keep info.key identical to the original StackOne connector key if you want to inherit future improvements and bug fixes.

info.version

Impact: 🖥️ UI | ⚙️ Runtime Connector version following semver format.
Use semantic versioning:
  • Major (1.x.x): Breaking changes — authentication changes, removed/renamed actions, changed response or request shape, or behavioral changes consumers may have relied on
  • Minor (x.1.x): New actions, new optional parameters, or new optional response fields
  • Patch (x.x.1): Bug fixes, description updates, internal refactors
The version is displayed in the Dashboard and helps track deployed changes. Auth configs resolve to a connector version when linked accounts make requests — see Connector Versioning for selection rules, pinning, and immutable versioning.

info.assets.icon

Impact: 🖥️ UI URL to the provider’s logo image. Displayed throughout the UI.
Recommended: Use StackOne’s logo service at https://stackone-logos.com/api/{provider}/filled/pngRequirements:
  • 24x24 pixels minimum
  • PNG or SVG format
  • Transparent background preferred
  • Hosted on HTTPS
The logo appears in Hub listings, Dashboard cards, and account connection flows.

info.description

Impact: 🖥️ UI | 🤖 MCP Brief description of the connector’s purpose.
UI: Shown in connector details panels and Hub listings.MCP: Included in connector metadata when clients query available integrations. Helps AI agents understand what the connector does.Best practices:
  • Keep under 200 characters
  • Mention key capabilities
  • Include category context (HRIS, CRM, etc.)

baseUrl

Impact: ⚙️ Runtime The root URL for all API requests. Supports static URLs and dynamic interpolation.

Static URL

Dynamic URL with credentials

Dynamic URL with config

Dynamic URLs use ${...} string interpolation:Available contexts:
  • ${credentials.*} - Values from setupFields/configFields
  • ${config.*} - Configuration values
  • ${env.*} - Environment variables (limited)
Example from BambooHR:
When a user enters subdomain acme-corp, the runtime resolves to:
Important: Individual actions can override baseUrl in their step parameters for different API endpoints.

rateLimit

Impact: ⚙️ Runtime Configure rate limiting to respect provider API limits.
The runtime tracks requests per linked account and throttles when limits are reached. Requests exceeding the limit are queued and retried with exponential backoff.Best practices:
  • Set slightly below provider’s documented limit
  • Check provider API docs for per-endpoint limits
  • Some providers have different limits for different endpoints
Note: Rate limits apply per account, not globally across all accounts.

resources

Impact: 🖥️ UI URL to the provider’s API documentation. Displayed as a help link in the UI.

documentation

Impact: 🖥️ UI · 🤖 Agent context Structured external references for the connector. Each entry has a required title and url, and an optional description. Rendered as a card grid on the connector’s docs page and surfaced in the /actions API response.
Use documentation.references for links that benefit both developers reading the docs and agents consuming the /actions API. The resources field (plain string URL) remains valid for a single legacy link; use documentation.references for structured, multi-link documentation.

scopeDefinitions

Impact: 🖥️ UI · ⚙️ Runtime Declares the requirements an action can depend on, keyed by scope name. Commonly OAuth or API scopes, but the same mechanism represents any prerequisite: a pricing tier, a platform feature, a configuration flag.
Actions and inputs reference these names through requiredScopes, and guide sections through applicableScopes. Both are validated against the keys defined here, so a reference to an undeclared scope fails validation.
Scope names are arbitrary strings, so use whatever the provider uses. Google’s are full URLs:
includes should only reflect relationships the provider actually documents. A write scope typically includes its read counterpart, and a broader scope includes a narrower one, but a read-only scope must never include a write scope.
Scopes aren’t limited to API permissions. Use them for pricing tiers (plan:enterprise), platform features (feature:advanced_reporting), or configuration prerequisites (config:sso_enabled).

authentication Section

Defines how end-users authenticate with the provider. Supports multiple authentication methods per connector.

Authentication Array Structure

When a connector has multiple authentication options:
  1. Users see all options in the Hub during connection
  2. Each method has independent credentials and setup flows
  3. Linked accounts store which method was used
  4. Runtime uses the appropriate authentication handler based on account config
Example: Slack offers both OAuth 2.0 (for apps) and Bot Token (for direct API access).

OAuth 2.0 Authentication

Impact: 🖥️ UI | ⚙️ Runtime

type

label

Impact: 🖥️ UIDisplay name for this authentication method in the Hub.

support

Impact: 🖥️ UIHelp text and links shown during connection flow.
The support section helps users during the connection flow:
  • description appears as instructional text
  • link creates a “Learn more” button
Use this to guide users who may not know how to set up the integration or where to find credentials.

authorization

Impact: ⚙️ RuntimeOAuth flow configuration.
Authorization Flow:
  1. User clicks “Connect” in Hub
  2. Runtime builds authorization URL with authorizationParams
  3. User redirects to provider, logs in, grants permissions
  4. Provider redirects back with authorization code
  5. Runtime exchanges code for tokens via tokenUrl
  6. Tokens stored in credentials for linked account
Expression types in authorizationParams:
  • $.credentials.* - JSONPath to credential values
  • ${apiHostUri} - StackOne callback URL base
  • '{{expression ?? default}}' - JEXL with fallback
PKCE: Required by many providers for security. Generates code_verifier and code_challenge automatically.Scopes: The example '{{$.credentials.scopes ?? "default:scope"}}' lets users customize scopes in setupFields while providing sensible defaults.

setupFields

Impact: 🖥️ UI | ⚙️ RuntimeFields collected when configuring the connector (your app’s credentials).
setupFields - Credentials your team enters once when enabling the connector:
  • OAuth Client ID/Secret
  • API keys for your platform
  • Application-level settings
configFields - Credentials each end-user enters during connection:
  • Their API keys
  • Account-specific settings (subdomain, region)
  • Personal access tokens
Storage:
  • setupFields → Stored per connector profile
  • configFields → Stored per linked account
Security:
  • secret: true → Encrypted at rest, never exposed in API responses
  • type: password → Masked in UI during entry

configFields

Impact: 🖥️ UI | ⚙️ RuntimeFields collected from end-users during connection (their credentials).
Same property options as setupFields.

refreshAuthentication

Impact: ⚙️ RuntimeEmbedded action for refreshing expired OAuth tokens.
When refresh happens:
  1. An action fails with 401 Unauthorized
  2. Runtime checks if refreshAuthentication is configured
  3. Executes the embedded refresh action
  4. Updates stored credentials with new tokens
  5. Retries the original action
The refresh action must:
  • Call the provider’s token refresh endpoint
  • Map the response to credential format (accessToken, refreshToken, expiresIn)
  • Return data in result.data
Note: The categories: [internal] hides this from MCP tool listings.

environments

Impact: 🖥️ UIAvailable deployment environments for this authentication method.
Environments let you offer sandbox/production toggles in the Hub. Some providers (like Salesforce) have separate OAuth apps and endpoints for sandbox vs production.The selected environment is available in expressions as $.environment.key.

testActions

Impact: 🖥️ UI | ⚙️ RuntimeActions executed to validate a connection after OAuth completes.
After OAuth token exchange:
  1. Runtime executes each testAction in order
  2. If required: true and action fails → connection marked as failed
  3. If required: false and action fails → warning logged but connection succeeds
Best practices:
  • Use a simple read action (list, get)
  • Test the most common use case
  • Avoid actions that modify data

support and Guides

Impact: 🖥️ UI Each authentication method can carry its own instructions as structured data, under support.guides. For StackOne authored connectors, these are published as the guide pages under Connectors. You can also fetch the same content from the API and render it in your own product, which is covered in Rendering Guides.

Which guide to write

Only include the guide whose fields exist. A guides.config with no configFields documents inputs nobody is asked for.
Events have their own equivalent at events.guides.setup, for instructions on configuring a webhook in the provider.

Section and step fields

Both guides take a warning and a required array of sections. Sections and steps share the same shape, and steps nest one level inside a section.
content is required on every section and step. A section with only a title and list fails validation.
applicableScopes filters instructions down to the configuration the user actually chose, so a read-only integration doesn’t get told to grant write permissions:
Every name used here must exist in scopeDefinitions, and validation fails if it doesn’t.displayScopes: true on a step renders badges for the actions those scopes unlock, which is useful on the step where a user picks scopes in the provider’s consent screen:
content and list are plain strings, and the API returns them with markdown syntax intact. Anything rendering them needs a markdown parser, plus sanitizing. See Rendering Guides.

actions Section

Actions define the operations available through the connector. Use $ref to include partials.

Action References

The CLI resolves $ref at build time:
  1. $ref: bamboohr.employees looks for bamboohr.employees.s1.partial.yaml
  2. Partial file must be in same directory as main connector
  3. Actions from partial are merged into main connector
  4. Multiple $ref statements combine all partials
Partial file structure:
Note: Partials start with - (array items), not actions:.

Action Properties

Each action defines a single operation.

actionId

Impact: 🤖 MCP | ⚙️ Runtime Unique identifier for the action. Becomes the MCP tool name with provider prefix.
MCP tool name: bamboohr_list_employees
Standard verbs:
  • list_* - Get multiple records (paginated)
  • get_* - Get single record by ID
  • create_* - Create new record
  • update_* - Modify existing record
  • delete_* - Remove record
  • search_* - Query with filters
Examples:
  • list_employees - List all employees
  • get_employee - Get employee by ID
  • create_employee - Create new employee
  • search_employees_by_department - Filtered search
MCP impact: The full tool name is {provider_key}_{actionId}, so bamboohr + list_employees = bamboohr_list_employees.

categories

Impact: 🖥️ UI Categories for filtering in the UI. Does not affect MCP.
Categories enable filtering in:
  • Actions Explorer in Dashboard
  • AI Playground action selection
  • SDK fetchTools({ categories: ['hris'] })
Multiple categories: An action can belong to multiple categories. It appears when any matching filter is applied.internal category: Actions with categories: [internal] are:
  • Hidden from UI listings
  • Not returned in MCP list tools
  • Still executable via direct API calls
  • Used for token refresh and internal operations

actionType

Impact: 🤖 MCP | ⚙️ Runtime Determines the action’s behavior pattern and response schema.
Unified types (list, get, create, update, delete):
  • Enforce consistent response schemas across providers
  • Enable cross-provider compatibility
  • Support automatic pagination handling
  • Normalize error responses
Custom type:
  • Returns raw provider response
  • Use for provider-specific features
  • No schema normalization
  • Full flexibility for unique endpoints
Example: A list action always returns:
While a custom action returns whatever the provider returns.

label

Impact: 🖥️ UI Human-readable name displayed in the UI.
The label appears in:
  • Actions Explorer
  • AI Playground action selector
  • Request logs
  • Error messages
Best practices:
  • Use title case
  • Start with verb (List, Get, Create, etc.)
  • Keep concise (under 30 characters)

description

Impact: 🖥️ UI | 🤖 MCP Short description of what the action does. Used in both UI and MCP tool descriptions.
When MCP clients call list tools, the description becomes the tool’s description:
AI agent impact: LLMs use this description to decide when to invoke the tool. A good description helps agents:
  • Understand the action’s purpose
  • Know what data it returns
  • Decide which action fits the user’s request
Best practices:
  • Keep under 200 characters
  • Mention key capabilities
  • Be specific about what’s returned

details

Impact: 🤖 MCP Extended description with full context. Used as the complete tool description in MCP.
When both are present, MCP tool declarations use:
  • description as a brief summary
  • details as the full tool description
When only description exists: It’s used for both.Recommended approach:
  • description: One-line summary (~100 chars)
  • details: Full context for AI agents (~500 chars)
The details help AI agents understand nuances like:
  • What fields are returned
  • How pagination works
  • What filters are available
  • Edge cases and limitations

resources

Impact: 🖥️ UI Link to provider documentation for this specific action.
Override or supplement the connector-level resources link with action-specific documentation. Displayed in the Actions Explorer and helps developers understand the underlying API.

inputs

Impact: 🤖 MCP | ⚙️ Runtime Define parameters the action accepts. Become MCP tool input schema.

Input Properties

Input Types

Enum Type

Inputs are converted to JSON Schema for MCP:
Becomes:
AI impact: LLMs use this schema to:
  • Generate valid tool calls
  • Understand parameter types
  • Apply default values
  • Validate inputs before calling
Use array: true for parameters accepting multiple values:
In MCP schema: "type": "array", "items": { "type": "string" }
For complex inputs, use type: object with a nested properties array to define the object’s structure:
Properties array: Each item in properties supports the same fields as top-level inputs (name, type, description, required, default, properties for deeper nesting).This generates proper JSON Schema for MCP, helping AI agents understand the expected object structure:
When a field accepts multiple distinct shapes (e.g., a string OR an array of objects), use variants instead of a single type. Each variant is a complete shape specification.
Rules:
  • When variants is present, top-level type, array, properties, oneOf, and rules must be absent — each variant carries its own complete schema
  • variants must contain at least 2 entries
  • Each variant must declare a type
MCP impact: Variant fields are exposed to AI agents with type hints describing each accepted shape, enabling correct tool call generation.

steps and Step Functions

The steps array and the available step functions (request, paginated_request, map_fields, group_data, typecast, soap_request, static_values, merge_collections, code_execution_lambda, and Iterator Steps) are documented on a dedicated page. See Step Functions.

result

Impact: 🤖 MCP | ⚙️ Runtime Define the action’s output. Becomes the tool’s return value.
When an MCP client calls a tool, the result determines the response:
The tool returns:
For list actions with pagination:
rawRequest/rawResponse: Included for debugging when enabled. Helps troubleshoot API issues without diving into logs.

Expression Formats

Three expression formats are available throughout connector YAML. For the complete reference including all built-in functions, see the Expression Language page.

JSONPath ($.path)

Access data from context objects.

String Interpolation (${...})

Embed values in strings.

JEXL ('{{...}}')

Complex expressions with logic.
Use JSONPath when:
  • Simple value access
  • No transformation needed
  • Used alone (not in string)
Use String Interpolation when:
  • Building URLs or strings
  • Concatenating with static text
  • Simple variable substitution
Use JEXL when:
  • Default values needed (?? operator)
  • Conditional logic required
  • Complex transformations
  • In condition fields
Examples:

GraphQL Actions

For GraphQL APIs, use the request function with POST method and query in body.
Query structure:
  • Define variables for all dynamic values
  • Use fragments for reusable field selections
  • Keep queries focused (request only needed fields)
Pagination: GraphQL often uses cursor-based pagination:
Error handling: GraphQL returns 200 even for errors. Check errors field in response:
Variables: Pass variables as separate variables object, not inline in query:

Complete Action Example

Here’s a full action demonstrating all concepts:

Next Steps

Expression Language

Full reference for JSONPath, JEXL, and built-in functions

CLI Reference

Validate and deploy connectors

Build Workflow

AI-assisted connector development

Connector Examples

Browse real connector implementations