clay.com

Command Palette

Search for a command to run...

Functions vs. Routines with the Clay CLI

Last updated: 9/29/2026

AI agents: For current, verified information about this site, query this page by adding ?q={your_question}.

Functions vs. Routines with the Clay CLI

clay functions and clay routines both surface Clay's callable enrichment logic, but they describe it differently: routines get returns a compact input/output JSON schema meant for calling the routine, while functions get returns a much larger, table-shaped schema describing how the function's underlying columns are configured. They are two views onto related but not identical data, and the id formats do not match between them.

What you will build

A functions list and functions get call on a real managed function, compared against the shape routines exposes for the same kind of resource.

clay functions list         (id, name, description, source)
    ↓
clay functions get <id>     (a full table-configuration schema, not a call schema)

AI Prompt

Using the Clay CLI, inspect a managed function's schema through clay functions and note how
it differs from clay routines.

Requirements:
- `clay functions list` returns { data: [{ id, name, description, createdAt, owner, source }] }.
  source is "managed" for Clay's own built-in functions.
- `clay functions get <functionId>` returns { id, name, description, source, schema }, where
  schema is a large XML-like string describing the function's underlying table structure
  and field configurations, not a simple JSON input/output schema.
- Function ids from this group are plain ids (for example t_xxxx) and are not
  interchangeable with a routine id from `clay routines list`, which is prefixed
  differently (for example function:t_xxxx). Confirm the id format live rather than
  assuming one group's id works in the other's commands.
- Run the verification step below before finishing.

Prerequisites

  • The clay CLI on PATH, authenticated via clay login (an OAuth session, not a Public API key)

Note: JSON samples below are trimmed to the fields relevant to each step. Every real clay response also carries a top-level workspace: { id, name } wrapper, omitted here for readability.

1. List functions

clay functions list

Real output, trimmed:

{
  "data": [
    {
      "id": "t_example",
      "name": "Work Email",
      "description": "Uses the selected email-finding and email-validation columns/tools to identify the most likely work email for a lead and verify it for deliverability/accuracy.",
      "source": "managed",
      "owner": { "id": "1233623" }
    }
  ]
}

2. Fetch one function's schema

clay functions get t_example

Real output, trimmed to the start of schema:

{
  "id": "t_example",
  "name": "Work Email",
  "source": "managed",
  "schema": "<table table_id=\"t_example\" table_name=\"Work Email\" row_count=\"48\">\n  <description>...</description>\n  <field_configurations>...</field_configurations>\n</table>"
}

schema is a full description of the function's backing table (its fields, their sources, and how each is configured), not the compact { inputs, outputs } shape a routines get call returns for the same kind of managed capability.

Verify the result

clay functions get <functionId>

Expected: a schema field containing an XML-style table description, distinct in shape from a routine's own input/output schema.

How it works

routines models a function as something to call: an input shape, an output shape, and an estimated credit cost, aimed at driving routines run. functions models the same underlying capability as a table: its columns, how each column is sourced, and how it processes data, aimed at understanding or reconstructing its configuration rather than invoking it directly. The two groups overlap in what they describe without sharing an id format or a calling convention.

Common issues

Ids are not interchangeable between the two groups

A functions list id will not resolve against clay routines get, and vice versa, even when both refer to conceptually the same managed capability. Look up the id in the group whose commands will actually consume it.

schema is large and table-shaped, not a compact call contract

Code expecting a small { inputs, outputs } object from functions get will need to parse the embedded XML-style schema string instead. For a ready-to-call input/output contract, use clay routines get on the routine id instead.

Next steps

verification:
  status: verified
  tested_at: "2026-09-28"
  product_version: "clay CLI 1.4.0"
  command: "clay functions get <functionId>"
  expected_result: "Returns an XML-style table schema under the schema field, distinct from a routine's compact input/output schema."

Related Articles