Map an integration's fields to a skill
Creates a skill on an agent by mapping a discovered integration operation: pick the operation, map your agent’s inputs to its arguments, and choose which provider fields to return. The mapping is validated against the integration’s discovered schema and compiles to a runnable skill — created as a draft unless you enable it. Connect and discover the integration first.
Authorizations
Flowyte secret API key (Authorization: Bearer flowyte_sk_live_…). Scope-gated; is scoped to your organization — a key can never reach another tenant. The listed scopes in each operation's apiKey requirement are the scopes that key must hold. The tokenUrl is nominal: keys are minted in the dashboard.
Path Parameters
The agent this resource is scoped to (the UUID returned by createAgent / listAgents).
The integration provider (connector). One of the supported connector slugs: native providers (google_calendar, google_sheets, calendly, hubspot, ``, square, opentable, shopify), SQL databases (postgres, mysql), the universal Zapier MCP fallback (zapier), or Composio (composio).
google_calendar, google_sheets, calendly, hubspot, square, opentable, shopify, postgres, mysql, zapier, composio Body
The LLM-facing tool/function name.
The provider operation to bind (a read e.g. clients
The LLM-facing tool description.
Bind a MUTATION. Gated (confirm + non-parallel; verified-identity for update/delete); the skill lands DISABLED for review.
Start enabled (reads only; a write always lands disabled).
READ: LLM param → provider operation argument.
WRITE: map a caller param OR an operator-pinned constant onto a field of the mutation's input object. Every required input field must be bound-or-const; sensitive PII classes are rejected.
Provider field path → canonical output leaf (leaf must be a scalar; a write may project the created id; userErrors is never projectable). For a SQL one-hop FK join, use path [relationshipField, targetColumn].
READ: mark this the caller-identity lookup (a phone search that greets a known caller by name). The runtime prefetches it and defaults the phone filter to the inbound caller number.
native_rest READ (a HubSpot-style CRM search): POST .../{object}/search with 1..5 ANDed filters. Use this (not inputs/projection) when the connected provider is a REST/OpenAPI CRM. A value the caller SPEAKS (name, company, subject) should filter with operator CONTAINS_TOKEN (partial match); an EXACT machine identifier (email, id) uses EQ. Find a caller by phone with the live-proven recipe — propertyName phone, operator CONTAINS_TOKEN, transform phone_token, callerIdFallback true (and set identifiesCaller). At least one filter must be caller-anchored (a param or callerIdFallback); a const-only search over-fetches a stranger and is rejected.
ASSOCIATION read (to-many): 2..5 returns an ARRAY of associated target rows (e.g. a company's contacts). Cap 1 (the default) returns the single flat target.
The snake_case array key the associated rows land under (associationCap>1 only).
native_rest WRITE (a HubSpot-style CRM create, or an update-by-id): map caller params/constants onto the object's OWN writable properties (no mass-assign). Gated (confirm + non-parallel) and lands DISABLED for review. Set findOrCreate to CAPTURE a returning caller without duplicating them.
native_sql READ (deterministic, LLM-free): exactly ONE filter on a LEADING-INDEX column. The transport (native_sql vs /native_rest) is determined by the connected provider's schema; use sqlSearch for postgres/mysql reads.
native_sql WRITE (deterministic): a single-row INSERT, or an UPDATE-by-unique-key (set keyColumn+keyParam). Gated; lands DISABLED for review. PII-classed columns are rejected.