Integration catalog

The catalog is the registry of every operation a task can perform. It is organized in a three-level hierarchy — Platforms contain Services, which contain Actions — and is fully browsable through public, unauthenticated endpoints. When you build a flow, each task names one action from the catalog and supplies parameters matching that action’s schema.

The hierarchy

Level	Example ID	What it is
Platform	`five9`	A third-party brand or provider.
Service	`five9__configuration_service`	A specific API the platform exposes.
Action	`five9__configuration_service__add_to_list`	A single operation on that service.

IDs follow a strict naming convention: segments joined by double underscores (__), each segment lowercase alphanumeric with single underscores. The ID encodes its own ancestry — an action ID is always platform__service__action, so five9__configuration_service__add_to_list tells you the platform (five9), the service (five9__configuration_service), and the operation (add_to_list) at a glance. A task references all three levels plus a version:

{
  "task_id": "task_1",
  "task_name": "Add to list",
  "platform_id": "five9",
  "service_id": "five9__configuration_service",
  "action_id": "five9__configuration_service__add_to_list",
  "action_version": "1.0",
  "connection_id": "cred_e5f6g7h8",
  "parameters": { "list_name": "Outbound Q3" }
}

action_version defaults to "1.0" and is reserved. The platform does not resolve action versions today: every task runs the single current implementation of the action it names, whatever this value says. The field is kept because per-account version pinning will need the slot, and it is validated in the meantime — if you supply an action_version that disagrees with the version the action is published at in the catalog, saving the definition is rejected with a 422 naming the field. The simplest thing to do is omit it and take the default.

Browsing the catalog

All catalog endpoints are read-only and require no authentication. List endpoints support status, limit (default 50), and skip query parameters.

Method	Endpoint	Returns
`GET`	`/catalog/platforms`	All platforms.
`GET`	`/catalog/platforms/{platform_id}`	One platform.
`GET`	`/catalog/platforms/{platform_id}/services`	A platform’s services.
`GET`	`/catalog/services/{service_id}`	One service.
`GET`	`/catalog/services/{service_id}/actions`	A service’s actions.
`GET`	`/catalog/actions/{action_id}`	One action, with its full parameter and output schemas.

curl "$BASE_URL/catalog/actions/five9__configuration_service__add_to_list"

Every catalog entry carries a status: active (usable now), coming_soon, and inactive (platforms and services) or deprecated (actions). The listings are the definitive answer to what you can use. Anything a listing returns can be named by a task in one of your flows; an ID that no listing returns is not available to you, and fetching it directly answers 404 exactly as an unrecognized ID does.

What each level tells you

Platform

Identity and discovery: name, icon, tags (e.g. contact-center, ccaas), and status. Use tags to find platforms by capability.Platforms that scope their own tenant boundary also carry tenancy_unit, the vocabulary that platform uses for that boundary — Five9 returns {"name": "Domain", "plural": "Domains", "key_field": "domain_id", "key_source": "getVCCConfiguration.domainId"}. Rate limits and quotas apply per unit, so this tells you what the limits are counted against. key_field names the field on the tenancy record holding the canonical identifier, and key_source records the provider call that resolves it. Platforms with no tenant boundary of their own return null.

Service

What the service is, and how it is spoken to. kind is the first fact: api for a service reached over a network, utility for a built-in that runs inside the platform, and mcp, cli or product for the other shapes a service can take.protocol says how an api is spoken to — REST, SOAP or GraphQL. It is null for anything that is not an api, because a built-in utility has no transport to name.auth_method is the one authentication mechanism the service speaks: basic_auth, api_key, jwt, oauth2, or none. It describes the credential material and how it is presented, and nothing else — it does not restate protocol, so a SOAP service using WS-Security over a username and password reports protocol: "SOAP" and auth_method: "basic_auth". A vendor product offering two mechanisms is published as two separate services, one per mechanism, so a credential is never ambiguous about which service it satisfies.requires_connection is derived from auth_method — it is true for every service whose auth_method is anything other than none. This is the field to read when you want to know whether a task calling this service must name a credential (in the task’s connection_id field); you never have to interpret the auth mechanism yourself, and the answer can never go stale against it. five9__configuration_service reports true; the built-in getdialed__utils reports false.Services also publish base_url, a docs_url pointing at the vendor’s own documentation, and rate_buckets — the provider’s documented rate limits, keyed by the provider’s own bucket name. See rate buckets below.

Action

The contract your task must satisfy: parameters, output_schema, an optional sample_output, and batching capability (batch_capable plus batch_settings). batch_settings is null for actions that are not batch-capable.An action also declares how it behaves. implementation is handler for an action that runs a single operation, or composite for one assembled from a flow. input_shape says what it consumes — scalar for a single set of values, record_set for a set of records, or either. retry_safety says how safe it is to repeat after an uncertain outcome: idempotent may be repeated freely, at_most_once must not be repeated blindly, and unsafe must never be repeated. Read retry_safety before you build a flow that reruns a step.batch_settings is returned in full by GET /catalog/actions/{action_id} — you no longer have to infer a per-call limit from batch_capable alone. For five9__configuration_service__add_to_list it reports

{"max_records_per_call": 50000, "supports_partial_success": true, "record_identifier_field": "number1", "merge_partition": "list_and_schema", "default_key_fields": ["number1"]}

. merge_partition says how queued items are grouped before they are sent — list_and_schema groups them by the destination list and column mapping, action_only groups by the action alone — and default_key_fields names the columns that identify a record when you declare none.

Rate buckets

A service’s rate_buckets field publishes the provider’s own documented rate limits. Each bucket is keyed by the name the provider uses for it (for Five9, its apiOperationType values such as Query, Modify, and Upload) and reports the caps per time window, in seconds:

{
  "rate_buckets": {
    "Upload": {
      "label": "Uploading (batch)",
      "windows": { "60": 20, "3600": 400, "86400": 2000 },
      "max_records_per_request": 50000,
      "min_interval_ms": null,
      "member_action_ids": ["five9__configuration_service__add_to_list"],
      "default_lane_by_action": {
        "five9__configuration_service__add_to_list": "bulk"
      },
      "default_lane": "bulk"
    }
  }
}

windows maps a window length in seconds — 60 (minute), 3600 (hour), 86400 (day) — to the maximum number of calls allowed in it. max_records_per_request is the per-call payload cap, or null where the provider documents none. min_interval_ms is the provider’s default minimum interval between two calls on this bucket — a spacing floor for providers whose real constraint is per-second rather than per-minute — or null where there is none. member_action_ids lists the actions that consume the bucket; an action can belong to more than one bucket when the provider documents it under several. default_lane_by_action and default_lane seed which named dispatch lane each action starts in — compliance, interactive, bulk, or backfill. An admin can override the placement per Domain; the catalog only supplies the default. The bucket keys are the provider’s own operation-type names — for Five9, its apiOperationType values — so a live counter reading from the platform maps onto these keys directly, with no translation table in between. That is what lets a Domain seed its caps from the catalog and then correct them against what Five9 actually reports.

These are the provider’s published limits for the platform as a whole, not your account’s remaining budget. Your account’s effective budget lives on the Domain record, which applies your safety margin on top of these caps. A single action can also consume more than one bucket, so pace high-volume writes against the tightest window that applies.

Action parameters

Each action publishes a complete schema for every parameter it accepts — enough to build the input form for it without knowing anything about the action in advance. Every field declares a type, a description, and a sensitivity classification; the rest are presentation and validation hints. Three of the parameters five9__configuration_service__add_to_list publishes:

{
  "parameters": {
    "list_name": {
      "type": "string",
      "description": "The name of the Five9 contact list the records are added to.",
      "sensitivity": "none",
      "required": true,
      "group": "Destination",
      "order": 1
    },
    "records": {
      "type": "array",
      "description": "The contact records to add. Supplied automatically when the step runs over a record set; each record carries its own list name and contact columns.",
      "sensitivity": "pii",
      "items": {
        "type": "object",
        "description": "One contact record, keyed by Five9 CRM column name.",
        "sensitivity": "pii"
      },
      "binding_sources": ["record_set"],
      "group": "Records",
      "order": 2
    },
    "key_fields": {
      "type": "array",
      "description": "The columns Five9 matches on to decide whether a record is a new contact or an update to an existing one. Defaults to number1, Five9's standard phone key.",
      "sensitivity": "none",
      "default": ["number1"],
      "items": {
        "type": "string",
        "description": "A Five9 CRM column name.",
        "sensitivity": "none"
      },
      "group": "Matching",
      "order": 3
    }
  }
}

Field	What it tells you
`type`	`string`, `number`, `boolean`, `object`, `array`, or `datetime`.
`description`	Human-readable text for the field. Always present.
`sensitivity`	How the value must be handled: `none`, `pii`, `phi`, or `secret`. Always present.
`required`	Whether the action refuses the call without it.
`default`	The value used when you supply none.
`enum`	The closed set of accepted values, when there is one.
`example`	A representative value.
`nullable`	Whether `null` is accepted.
`items`	For an `array`, the schema of one element.
`properties`	For an `object`, the schemas of its members.
`group`, `order`	Suggested grouping and ordering for a generated form.
`secret`	Whether the value must be masked. Always `true` when `sensitivity` is `secret`.
`hidden`	The platform supplies this value; it is not for you to fill in.
`binding_sources`	Where a value may be drawn from instead of being typed in — for example `record_set` for a field taken from the records a job is iterating.

sensitivity is the field to read before you log, store, or forward a value. Every parameter carries one — there is no unclassified field — so a pii or secret input is always identifiable from the catalog alone, without knowing what the action does. Your task’s parameters object supplies these values, with expressions anywhere you need runtime data. The output_schema documents the fields the action returns using the same field schema, which downstream steps can reference as {{step_id.task_id.output.<field>}}.

What is checked when you save

A flow definition is validated against the catalog at save time, so a task that could never run is rejected before it ever gets scheduled. Each of these returns a 422 naming the offending step, task, and field:

Rejected when	Why
`action_id` names an action the catalog does not list	The task has nothing to run.
The action is no longer available for use	Its `status` is not `active`. An existing definition that already referenced that action keeps working, so a retirement does not brick flows you have already saved.
The action’s service needs a credential and the task names none	Read `requires_connection` on the service to know in advance.
`action_version` disagrees with the catalog	See above — the field is reserved, and a value that contradicts the catalog is a claim the platform will not honor silently.

Only the first problem per task is reported, so fix them one at a time; problems in different tasks are all reported together in a single response.

What’s in the catalog

Five9 is the flagship platform: contact center operations against the Five9 Configuration Service, including dialing-list actions like five9__configuration_service__add_to_list and compliance actions like five9__configuration_service__add_numbers_to_dnc, which adds numbers to your domain’s Do Not Call list. DNC is bidirectional: five9__configuration_service__remove_numbers_from_dnc takes numbers back off the list. These actions require a credential holding your Five9 login, and the list operations are batch-capable for batched delivery.

Both DNC actions are batch-capable and declare supports_partial_success: false — one invalid number rejects the whole request. See batching before sending large DNC groups.

Removing a number from DNC deletes a consumer’s opt-out. Treat remove_numbers_from_dnc as a corrective action for numbers added in error, and confirm the removal is authorized before you run it — Five9 accepts the request without validating the numbers, and the action reports only how many were actually removed.

GetDialed built-ins (the getdialed platform) run inside the platform and need no credential. There are three services, and each declares auth_method: "none", so requires_connection is false and tasks calling their actions name no credential. getdialed__utils — general helpers:

Action	What it does
`getdialed__utils__sleep`	Waits for `duration_seconds` (default 60) before continuing — use it to space out the steps of a flow, for example to leave time for a system you just wrote to before reading back from it.
`getdialed__utils__emit_event`	Publishes a business event by name. Every flow subscribed to that event name starts, receiving the event body as its input — so one flow can trigger others without either naming the other.
`getdialed__utils__trigger_flow`	Hands a set of records to a named flow and starts it — in bulk, or one run per record. See record transforms.
`getdialed__utils__echo`	Returns the message it was given. A harmless first step for trying out a flow end to end.

getdialed__records — record transforms, each reading a set of records and producing a new one:

Action	What it does
`getdialed__records__map_fields`	Builds a new set with the columns you name, written from expressions over each record.
`getdialed__records__lookup_table`	Translates a column’s values through a table of yours into another column.
`getdialed__records__filter`	Keeps only the records matching a set of structured conditions.
`getdialed__records__dedupe`	Keeps one record per distinct value of the columns you choose.
`getdialed__records__sort`	Puts a set in order, optionally keeping only the first few.
`getdialed__records__aggregate`	Counts, totals and summarises — over the whole set or once per group.
`getdialed__records__split`	Splits one set into several, named after the value they were grouped by.
`getdialed__records__merge`	Combines several sets into one, keeping everything or first-per-key.
`getdialed__records__parse_csv`	Reads comma-separated text already in the flow into a set of records.
`getdialed__records__parse_json`	Reads JSON text already in the flow into a set of records.
`getdialed__records__parse_xml`	Reads XML text already in the flow into a set of records.

getdialed__data — writes into a data store:

Action	What it does
`getdialed__data__write_store_layer`	Writes a record set into one named source layer of a store, with the store’s own normalization, precedence, history and events.

The quickstart builds its first flow from a built-in utility action, so you can see the full trigger-to-result loop before setting up any credentials.

Next steps

Credentials

Store the secrets for the platforms your tasks call.

Flow definitions

Assemble catalog actions into steps and tasks.

Batched delivery

Use batch-capable actions for high-volume writes.

API reference

Full request and response schemas for every catalog endpoint.

Getting Started

Core Concepts

Building Flows

Triggers & Streaming

The hierarchy

Browsing the catalog

What each level tells you

Rate buckets

Action parameters

What is checked when you save

What’s in the catalog

Next steps

Credentials

Flow definitions

Batched delivery

API reference

​The hierarchy

​Browsing the catalog

​What each level tells you

​Rate buckets

​Action parameters

​What is checked when you save

​What’s in the catalog

​Next steps

Credentials

Flow definitions

Batched delivery

API reference

The hierarchy

Browsing the catalog

What each level tells you

Rate buckets

Action parameters

What is checked when you save

What’s in the catalog

Next steps