@alvera-ai/platform-sdk 0.21.1 → 0.21.2

package/.agent/data_activation_clients.md

@@ -389,7 +389,7 @@ const { data } = await api.dataActivationClients.ingest(
   tenantSlug, datalakeSlug, activationClientSlug,
   { data: rowAsJson },                  // a single row, shaped per the CSV/JSON the contracts expect
 )
-// data.batch_id   — UUID; the row's batch identifier (use to find log rows)
+// data.batch_id   — UUID; the run's batch identifier (use to find the run's log rows)
 // data.key        — storage key for the row's archived ndjson
 // data.jobs_count — number of downstream jobs the platform enqueued
 ```
@@ -400,8 +400,11 @@ been written, poll the logs (§6.4) or use the verification
 pattern (§6.6).
 
 The `batch_id` is the most important field on the response —
-every downstream log row and dataset row carries the same
-`batch_id`, so it's the join key for run-specific verification.
+every log row the run writes carries it, and every dataset row the
+run writes points at one of those log rows through
+`alvera_data_activation_log_id`. A dataset row carries no
+`batch_id` of its own, so the batch reaches the rows through the
+log rows: that is the join for run-specific verification.
 
 ### 6.2 Bulk file ingestion — `.ingestFile`
 
@@ -490,8 +493,9 @@ batch_id            UUID — the run's batch identifier
 dataset_table       string — the target dataset/table name
 rows_ingested       number — count of top-level rows the contract emitted
                               (cascade rows carry 0)
-dataset_updated     number — count of dataset rows whose batch_id this run wrote
-                              (load-bearing: see Gotcha 7)
+dataset_updated     number — count of dataset rows that point at this log row
+                              (each row the run writes carries its log row's id in
+                              alvera_data_activation_log_id; load-bearing: see Gotcha 7)
 output_files        { object_key, mode }[] — merged ndjson archive refs, one per
                                 bucket; mode is 'raw' | 'tokenized' | 'redacted'
                                 (empty until the post-batch merge worker commits).
@@ -639,29 +643,32 @@ spends its full timeout and then reports nothing about the cause.
 
 ### 6.6 Verifying ingestion: the two-step dataset search
 
-> **Simplest landing check — `executeSql`.** Ingestion is async (the row
-> commits a moment after the `202`). When you just need to know a row
-> *landed*, poll `datalakes.executeSql` with a read-only `SELECT … WHERE
-> batch_id = '…'`: **each call is a fresh read, so there is no stale
-> snapshot to recover from** — unlike a `createUserSearch` created before
-> the row commits, which captures nothing and never updates. Gate on it,
-> then run the two-step `createUserSearch` below **once** (race-free) only
-> if you need the dataset's alias-join + tokenization semantics.
+> **Simplest landing check — the run's own log rows.** Ingestion is async
+> (the row commits a moment after the `202`). When you just need to know
+> rows *landed*, read the run's log rows (§6.4) filtered by its
+> `batch_id`. Every dataset row the run writes points at the log row for
+> its table, and that log row's `dataset_updated` counts it — so the log
+> rows answer the question with no query on the dataset table and no
+> table name to know. A dataset row carries no `batch_id` of its own to
+> filter on. **Each call is a fresh read, so there is no stale snapshot to
+> recover from** — unlike a `createUserSearch` created before the row
+> commits, which captures nothing and never updates. Gate on it, then run
+> the two-step `createUserSearch` below **once** (race-free) only if you
+> need the dataset's alias-join + tokenization semantics.
 >
 > ```typescript
-> const { data: probe } = await api.datalakes.executeSql(tenantSlug, datalakeSlug, {
->   sql: `SELECT 1 FROM ${tableName} WHERE batch_id = '${batchId}' LIMIT 1`,
->   mode: 'raw',
-> })
-> // `data` is an array-of-arrays (a `string` only for { format: 'csv' });
-> // a non-empty page proves the batch landed. The table is named the same
-> // in every lake — `mode` selects which copy answers, not which name.
-> const landed = typeof probe !== 'string' && probe.data.length > 0
+> const { data: logs } = await api.dataActivationClients.logs.list(
+>   tenantSlug, datalakeSlug, activationClientSlug,
+>   { filters: [{ field: 'batch_id', op: '==', value: batchId }] },
+> )
+> // One log row per dataset table the run wrote into; each counts the rows
+> // that point at it. A sum above zero proves the batch landed.
+> const landed = (logs.data ?? []).reduce((n, log) => n + (log.dataset_updated ?? 0), 0) > 0
 > ```
 >
 > `createUserSearch` is the heavier, workflow-oriented surface — reach for
-> it when you need its alias joins (`ri.value`, tokenized read-back), not
-> for a plain "did it land" check.
+> it when you need the rows themselves: its alias joins, tokenized
+> read-back. Not for a plain "did it land" check.
 
 The canonical way to **prove a row landed in the datalake** is
 to query the dataset directly. This is a two-step pattern:
@@ -683,7 +690,8 @@ const { data: search } = await api.datasets.createUserSearch(
   'patient',                                              // dataset name
   {
     search_query: `ri.value = '${externalPatientId}'`     // SQL WHERE-clause fragment
-                   + ` AND le.batch_id = '${batchId}'`,
+                   + ` AND le.alvera_data_activation_log_id IN`
+                   + ` (SELECT id FROM data_activation_logs WHERE batch_id = '${batchId}')`,
   },
 )
 // search.id            — UUID of the materialised result set
@@ -736,8 +744,46 @@ a patient or an appointment is now a generic table you declare, plus
 the legal entity its rows resolve to**; there is no dataset of that
 name to search. The four cookbooks all take this shape.
 
-The `<alias>.batch_id` predicate scopes a search to one run, which is
-the usual reason to reach for this surface at all.
+Scoping a search to one run is the usual reason to reach for this
+surface at all, and it goes **through the log row**. A row carries no
+`batch_id`, `client_id`, `user_id` or `source_uri` of its own: it
+carries `alvera_data_activation_log_id`, the `data_activation_logs` row
+of the ingest that wrote it, and the batch lives there. So the
+predicate is
+
+```
+<alias>.alvera_data_activation_log_id IN
+  (SELECT id FROM data_activation_logs WHERE batch_id = '<batch_id>')
+```
+
+The search runs with read access across the whole lake, so
+`data_activation_logs` is readable from inside it. The pointer is null
+on a row nothing ingested (a row an app wrote itself), so such a row
+never matches a batch predicate.
+
+#### Where a row came from, coming back
+
+A searched row carries the pointer **and** the log row it points at,
+loaded. Measured on a live run — one legal entity, one generic-table row
+— the platform columns that come back are:
+
+```
+id                             string
+inserted_at / updated_at       string
+checksum                       string
+checksum_changed?              boolean   (the key has the question mark)
+legal_entity_id                string    (generic-table rows)
+alvera_data_activation_log_id  string    (null on a row no ingest wrote)
+alvera_data_activation_log     object    — the log row itself:
+    id, batch_id, client_id, user_id, source_uri, dataset_table,
+    rows_ingested, dataset_updated, status, error, input_files,
+    output_files, inserted_at, updated_at
+```
+
+So "which batch wrote this row?" is `row.alvera_data_activation_log.batch_id`,
+and "where did it come from?" is `row.alvera_data_activation_log.source_uri` —
+there is no top-level `batch_id`, `client_id`, `user_id` or `source_uri` on
+the row unless the table declared a column of that name itself.
 
 #### What a masked column looks like coming back
 
@@ -807,13 +853,13 @@ screen. Pick the mode by which of those two readers you are serving.
    pattern in §6.6) before treating the row as ingested.
 
 7. **`dataset_updated > 0` is the load-bearing freshness
-   gate.** `rows_ingested` flips as soon as the per-row job
-   completes, but the dataset row's `batch_id` column is
-   updated by a downstream trigger that can lag. Filtering a
-   `.createUserSearch` by `<base_alias>.batch_id = '<this>'`
-   BEFORE that trigger fires returns an empty result set,
-   and there's no way to refresh the materialised result —
-   you'd have to POST a new search. Poll for
+   gate.** `rows_ingested` counts rows the contract emitted —
+   received, not persisted. `dataset_updated` counts the dataset
+   rows that point at the log row, so it moves only when a row
+   has been written. A `.createUserSearch` scoped to the batch
+   (§6.6) issued BEFORE the rows are written returns an empty
+   result set, and there's no way to refresh the materialised
+   result — you'd have to POST a new search. Poll for
    `dataset_updated > 0` before issuing the search.
 
 8. **`output_files` empty ≠ batch failed.** A log row with

package/.agent/generic_tables.md

@@ -168,6 +168,7 @@ On a `none` column it is documentation and costs nothing.
    datetime    timestamp with timezone
    time        time of day (no date component)
    jsonb       arbitrary JSON document
+   uuid        identifier; reads back as a uuid string, not raw bytes
 ```
 
 `decimal` and `float` are distinct on purpose: `decimal` emits a
@@ -297,21 +298,49 @@ data activation clients use as the upsert key.
 
 ### Reserved column names
 
-The platform reserves certain column names you cannot redeclare
-in `columns[N].name`:
+The platform creates every generic table with the same seven base
+columns, and they are yours to read but never to declare in
+`columns[N].name`:
 
-The platform creates every generic table with the same base columns,
-and they are yours to read but never to declare:
+```
+   id                             uuid primary key
+   inserted_at                    timestamp
+   updated_at                     timestamp
+   checksum                       the row's content fingerprint
+   checksum_changed               whether the last write changed it
+   legal_entity_id                the subject the contract's MDM resolve stamped
+   alvera_data_activation_log_id  the data_activation_logs row of the
+                                  ingest that wrote the row
+```
+
+**Where the batch, the client, the user and the source went.** A row
+does not carry them. It carries `alvera_data_activation_log_id`, a
+pointer to the `data_activation_logs` row of the ingest that wrote it,
+and the batch, the client, the user and the source live on that log
+row. The pointer is **null on a row nothing ingested** — a row an app
+wrote straight into the table. To pick out one ingest's rows in SQL, go
+through the log row:
 
 ```
-   id             uuid primary key
-   inserted_at    timestamp
-   updated_at     timestamp
-   batch_id       the ingest run that wrote the row
-   client_id      the activation client that wrote it
-   legal_entity_id the subject the contract's MDM resolve stamped
+<table>.alvera_data_activation_log_id IN
+  (SELECT id FROM data_activation_logs WHERE batch_id = '<batch_id>')
 ```
 
+Because those four are no longer platform columns, they are no longer
+reserved: a table may declare its own `batch_id`, `client_id`,
+`user_id` or `source_uri`, and it is plain data like any other column.
+
+**`id` may be named once: inside the unique combination.** A
+definition must name a unique combination, and a table is sometimes
+unique only together with its id — say `(organization_id, id)`.
+Declaring `id` with `is_unique: true` puts it in that combination and
+adds no column (every table already has one). Declared any other way,
+`id` is a reserved name like the rest. And it may join the combination,
+never be the whole of it: create accepts a table whose only unique
+column is `id`, but the column sync drops reserved names before it
+reads the unique columns, finds none, and fails every migrate of the
+lake, which stays at `new`. Mark a column of the table's own unique.
+
 **`legal_entity_id` is the one that catches people.** It is not a
 column you declare and fill — a contract's `mdm_input_config`
 resolves the subject and the platform stamps it. Declaring a column

package/.agent/interoperability_contracts.md

@@ -298,8 +298,8 @@ in the datalake and there is nothing to search afterwards. The
 `upsert_into_datalake` step (the DB insert, routed by the
 contract's `resource_type` destination) runs only when the DAC
 worker ingests a row — i.e. on `dataActivationClients.ingest`, not
-on `.run`. To prove a row *landed*, ingest and then query by
-`batch_id` (see `data_activation_clients.md` §6.6).
+on `.run`. To prove a row *landed*, ingest and then read the run's
+log rows for its `batch_id` (see `data_activation_clients.md` §6.6).
 
 ```typescript
 const { data: result } = await api.interoperabilityContracts.run(
@@ -592,8 +592,8 @@ surface, and `workflows.md` for the workflow side of the same join.
    `'checking'` PASSES `.run(slug, row)` — the sandbox renders
    JSON without casting the enum — but is rejected at live
    ingest: the batch reports `rows_ingested` yet the row never
-   persists (`dataset_updated` stays `0`; a `batch_id` query
-   returns nothing). Sandbox-run (§7.4) proves the shape, not the
+   persists (`dataset_updated` stays `0`; no row points at the
+   batch's log row). Sandbox-run (§7.4) proves the shape, not the
    enum domain — ground every enum value against the platform
    schema or a known-good fixture, never intuition.
 

package/.agent/mock-services.md

@@ -14,9 +14,11 @@ third-party APIs the platform integrates with — Athenahealth, Twilio, Mailgun,
 Stripe, SendGrid, HubSpot, QuickBooks, Airtable, Atomic FI, the LLM providers,
 and a small set of AWS endpoints MiniStack cannot serve.
 
-**MiniStack** serves AWS itself: `s3,lambda,sns,ssm,sqs,sts,logs,secretsmanager,cloudformation`
+**MiniStack** serves AWS itself: `s3,lambda,sns,ssm,sqs,sts,logs,secretsmanager,cloudformation,rds,ses`
 (`local-dependencies.yml`). See [Datalakes](datalakes.md) for how datalake
-provisioning uses it.
+provisioning uses it. An SES email tool whose endpoint URL is `http://localhost:4566`
+sends into MiniStack, which lists every message it received at
+`http://localhost:4566/_ministack/ses/messages`.
 
 The division is not arbitrary. No AWS emulator here serves
 `pinpoint-sms-voice-v2` — LocalStack Community answered 501 (Ultimate tier

package/.agent/templates.md

@@ -90,7 +90,12 @@ trying to add to the catalog.
    sub-directories under that prefix ship the same basename (e.g.
    two vendors under `data_activation/interoperability/`),
    `metadataDetails` returns `409 Conflict` with the candidate
-   paths; a missing basename returns `404`.
+   paths; a missing basename returns `404`. This bites status
+   templates: Mailgun and SES both ship an `email_message_status`
+   under `status_poller`, so the bare `email_message_status`
+   answers 409 — name the provider's path
+   (`status_poller/aws_ses/email_message_status`), as the bare
+   `sms_message_status` already required.
 
 2. **`output_schema` may be `null`.** Some templates render plain
    strings without structured output. Test for null before

package/.agent/tools.md

@@ -92,8 +92,9 @@ the discriminator. Each branch is its own TypeScript type:
    tool_body_type = 'email'          →  dedicated email-provider body
                                         (Mailgun, SendGrid, SES,
                                          SMTP-bridge; optional
-                                         endpoint_url overrides the
-                                         provider base URL)
+                                         endpoint_url: for SES the
+                                         whole request URL, for
+                                         Mailgun the API base URL)
                                         — alternative to using
                                         rest_api for email intents
 ```
@@ -274,6 +275,15 @@ Each branch has its own required-list. Common patterns:
                               probe; blank ⇒ each service resolves to
                               its own regional AWS host)
 
+   email body, provider ses from_email, region, access_key_id +
+                              secret_access_key (a long-lived IAM key:
+                              there is no session-token field, so
+                              temporary credentials cannot send);
+                              optional endpoint_url — the WHOLE request
+                              URL, e.g. a local AWS stand-in at
+                              http://localhost:4566; blank ⇒
+                              https://email.<region>.amazonaws.com
+
    sql_database body        db_type, db_host, db_port, db_name,
                               auth_method, db_username,
                               db_password (or iam_role)
@@ -788,12 +798,10 @@ usable as a proof — three things to get right:
   asynchronously, so the response carries the PREVIOUS run's stamps.
   Capture `last_run_at` as a baseline BEFORE calling it, then poll the
   row until `last_run_at` advances past that baseline.
-- **`last_run_status` has three values.** `'ok'` means the run completed
-  and read its whole time window; `'partial'` means the provider fetch was
-  truncated, so the newest events may be missing and `last_run_error`
-  carries the detail; `'error'` means the run failed. Only
-  `last_run_status === 'ok'` proves a complete reconciliation — a
-  `!== 'error'` check silently accepts a truncated `partial`.
+- **`last_run_status` has two values.** `'ok'` means the run read its
+  whole time window; `'error'` means it stopped, and `last_run_error`
+  says why. There is no partial run: every page of the window is read,
+  one job per page, with no page cap.
   `last_run_events_found` counts the current run's events, and because
   `refresh` is async an early read can show an in-progress figure.
 - **`status` is the halt flag.** It is `'active'` normally and the

package/.agent/workflows.md

@@ -441,6 +441,17 @@ variable. Field paths match the columns of the workflow's
 For generic-table-bound workflows, `event_dataset` carries the
 table's columns directly (no separate `row` indirection).
 
+**Where the row came from is on its log row, not on the row.** A row
+carries no `batch_id`, `client_id`, `user_id` or `source_uri` of its
+own: it points at the `data_activation_logs` row of the ingest that
+wrote it, and templates read that log row loaded on the event —
+`event_dataset.alvera_data_activation_log.source_uri`,
+`event_dataset.alvera_data_activation_log.batch_id`. It is null when
+the row came from no ingest (an app wrote it straight into its table),
+so guard a template that reads it. A generic table may declare its
+own column called `source_uri` or `batch_id`; then
+`event_dataset.source_uri` is that column, plain data.
+
 ### `skip_mdm_resolution` is a deliberate choice, not a generic-table default
 
 `skip_mdm_resolution` (default `false`) opts the workflow out of the
@@ -566,8 +577,12 @@ reads as "leave it alone" on the wire and as "remove it" in the author's head.
 Caller-supplied fields **inside each `actions[*]`** row:
 
 ```
-action_type                  required enum — 'sms' | 'email' | 'voice' | 'data_exchange'
-tool_id                      required UUID — tool.intent must match action_type
+action_type                  required enum — 'sms' | 'mms' | 'email' | 'voice'
+                                              | 'data_exchange' | 'data_activation'
+tool_id                      UUID — tool.intent must match action_type. Required
+                                              for every action type EXCEPT
+                                              data_activation, which refuses one
+                                              (its client carries its own tool)
 decision_key                 required string — unique within the workflow
 trigger_template             required string — schedule; 'now'/'' = immediate,
                                               else local ISO 8601 in datalake tz (§2)
@@ -585,6 +600,49 @@ Inside `tool_call`, the `sms_request`, `mms_request` and `email_request`
 variants also take `link_prefix` (**required**) and `link_validity_days`
 (optional, default 365) — see §7.
 
+### The `data_activation` action runs a client for the row
+
+An action of type `data_activation` sends nothing. It runs a data
+activation client — the one `client_slug` names, in the workflow's own
+datalake — for the row that started the workflow. Its tool call is
+`run_data_activation_client`, and it names no tool: the client carries
+its own, so an action with a `tool_id` is refused.
+
+```typescript
+import { ActionType } from '@alvera-ai/platform-sdk'
+
+const fetchMemberAction = {
+  action_type: ActionType.DATA_ACTIVATION,   // no tool_id: the client carries its own tool
+  decision_key: 'fetch_member',
+  trigger_template: 'now',
+  idempotency_template: '{{ event_dataset.message_id }}-fetch',
+  tool_call: {
+    tool_call_type: 'run_data_activation_client',
+    client_slug: 'fetch-member',
+    tool_call_override_template:
+      `{"tool_call_type": "sql_query", "query": {"type": "custom", "body": "SELECT * FROM inbound_messages WHERE message_id = '{{ event_dataset.message_id }}'"}}`,
+  },
+}
+```
+
+The questions a builder asks about it:
+
+- **What does the override do?** `tool_call_override_template` is
+  Liquid rendered against the row (`event_dataset`) to the client's
+  WHOLE tool call as JSON — the same shape `.runManually` takes as its
+  one-shot override (`data_activation_clients.md` §6.3). An override of
+  the same `tool_call_type` as the client's stored call is merged over
+  it; one of another type replaces it.
+- **Does it change the client?** No. The override applies to that one
+  run; the client's stored tool call — a scheduled query, say — is
+  untouched.
+- **Two rows at once?** Each row's action is its own run of the client,
+  with its own rendered override, and runs beside any scheduled run
+  rather than merging into it.
+- **How do I see what it did?** The client's run is an ordinary data
+  activation run: read it back through the client's runs and log rows
+  (`data_activation_clients.md` §6.4–§6.5).
+
 **Write-only (Request-only).** None.
 
 ## 5. Lifecycle

package/dist/index.d.mts

@@ -679,7 +679,7 @@ type ActionStatusUpdaterResponse = {
    */
   readonly last_run_at?: string | null;
   /**
-   * Why the last poll run failed, or why a `partial` run was truncated; null when the run completed and read its whole window
+   * Why the last poll run failed; null when the run completed and read its whole window
    */
   readonly last_run_error?: string | null;
   /**
@@ -687,9 +687,9 @@ type ActionStatusUpdaterResponse = {
    */
   readonly last_run_events_found?: number | null;
   /**
-   * Outcome of the last poll run. `partial` means the run completed but its provider fetch was truncated, so the window was not fully read and the newest events may be missing — read `last_run_error` for detail.
+   * Outcome of the last poll run: `ok` when the run read its whole window, `error` when it stopped — read `last_run_error` for why. A run is never partial: every page of the window is read, one job per page.
    */
-  readonly last_run_status?: 'ok' | 'partial' | 'error';
+  readonly last_run_status?: 'ok' | 'error';
   message_config: SimpleTemplateConfigResponse;
   /**
    * Updater name
@@ -990,6 +990,7 @@ declare enum ActionType {
   EMAIL = "email",
   VOICE = "voice",
   DATA_EXCHANGE = "data_exchange",
+  DATA_ACTIVATION = "data_activation",
 }
 /**
  * MDMVerifyRequest
@@ -1185,11 +1186,13 @@ type ActionResponse = {
     tool_call_type: 'aws_lambda_request';
   } & ActionAwsLambdaCallResponse) | ({
     tool_call_type: 'manual_upload';
-  } & ActionManualUploadCallResponse);
+  } & ActionManualUploadCallResponse) | ({
+    tool_call_type: 'run_data_activation_client';
+  } & ActionRunDataActivationClientCallResponse);
   /**
-   * Tool that executes this action
+   * Tool that executes this action. Required for every action type except data_activation, which refuses one: its client carries its own tool.
    */
-  tool_id: string;
+  tool_id?: string | null;
   /**
    * Liquid template that determines when this action executes
    */
@@ -1663,6 +1666,21 @@ type SystemTemplateListResponse = {
 type DataActivationClientS3CallResponse = S3CallResponse & {
   tool_call_type: 's3_request';
 };
+/**
+ * RunDataActivationClientCallRequest
+ *
+ * Runs a data activation client for the row that started the workflow, with the tool call the template renders for that row in place of the client's stored one. Request
+ */
+type RunDataActivationClientCallRequest = {
+  /**
+   * Slug of the data activation client to run, in the workflow's datalake
+   */
+  client_slug: string;
+  /**
+   * Liquid template rendered against the row that started the workflow, to the client's whole tool call as JSON — the shape the run-manually endpoint takes. It replaces the client's stored tool call for this run only.
+   */
+  tool_call_override_template: string;
+};
 /**
  * EmailCallResponse
  *
@@ -1786,10 +1804,10 @@ type GenericTableListResponse = {
 /**
  * MMSCallResponse
  *
- * MMS tool-call config — Liquid-templated recipient and body, plain public media URL, and the prefix its links go out on.
+ * MMS tool-call config — Liquid-templated recipient, optional caption, plain public media URL, and the prefix its links go out on.
  */
 type MmsCallResponse = {
-  body: SimpleTemplateConfigResponse;
+  body?: SimpleTemplateConfigResponse;
   /**
    * Address of the host that serves this action's links. Every URL in the body goes out as <link_prefix>/<token>. An absolute http or https URL, path allowed, with no query, fragment or trailing slash.
    */
@@ -2232,7 +2250,7 @@ type GenericTableColumnResponse = {
   /**
    * Column data type
    */
-  type: 'string' | 'integer' | 'float' | 'boolean' | 'date' | 'datetime' | 'time' | 'decimal' | 'jsonb';
+  type: 'string' | 'integer' | 'float' | 'boolean' | 'date' | 'datetime' | 'time' | 'decimal' | 'jsonb' | 'uuid';
 };
 /**
  * DatasetSearchResponse
@@ -2373,6 +2391,12 @@ type AuthenticatedLinkUpdateMessageTrackingRequest = {
 type DataActivationClientSftpCallResponse = SftpCallResponse & {
   tool_call_type: 'sftp_request';
 };
+/**
+ * ActionRunDataActivationClientCallResponse
+ */
+type ActionRunDataActivationClientCallResponse = RunDataActivationClientCallResponse & {
+  tool_call_type: 'run_data_activation_client';
+};
 /**
  * DataSourceRequest
  *
@@ -2615,6 +2639,21 @@ type AlveraApiError = {
    */
   mode?: string | null;
 };
+/**
+ * RunDataActivationClientCallResponse
+ *
+ * Runs a data activation client for the row that started the workflow, with the tool call the template renders for that row in place of the client's stored one.
+ */
+type RunDataActivationClientCallResponse = {
+  /**
+   * Slug of the data activation client to run, in the workflow's datalake
+   */
+  client_slug: string;
+  /**
+   * Liquid template rendered against the row that started the workflow, to the client's whole tool call as JSON — the shape the run-manually endpoint takes. It replaces the client's stored tool call for this run only.
+   */
+  tool_call_override_template: string;
+};
 /**
  * CloudStorageAwsResponse
  *
@@ -3438,7 +3477,7 @@ type EmailResponse = {
    */
   domain?: string;
   /**
-   * Custom Mailgun API base URL (e.g., https://api.eu.mailgun.net/v3 for EU domains, or a WireMock endpoint for integration tests); leave blank for real Mailgun
+   * Custom provider endpoint; leave blank for the real provider. For SES, the whole request URL (e.g., http://localhost:4566 for MiniStack); blank means https://email.<region>.amazonaws.com. For Mailgun, the API base URL (e.g., https://api.eu.mailgun.net/v3 for EU domains, or a WireMock endpoint for integration tests)
    */
   endpoint_url?: string | null;
   /**
@@ -4205,7 +4244,7 @@ type GenericTableColumnRequest = {
   /**
    * Column data type
    */
-  type: 'string' | 'integer' | 'float' | 'boolean' | 'date' | 'datetime' | 'time' | 'decimal' | 'jsonb';
+  type: 'string' | 'integer' | 'float' | 'boolean' | 'date' | 'datetime' | 'time' | 'decimal' | 'jsonb' | 'uuid';
 };
 /**
  * CloudWatchQueryResponse
@@ -4738,10 +4777,10 @@ type InteroperabilityContractAiAgentRequestWritable = {
 /**
  * MMSCallRequest
  *
- * MMS tool-call config — Liquid-templated recipient and body, plain public media URL, and the prefix its links go out on. Request
+ * MMS tool-call config — Liquid-templated recipient, optional caption, plain public media URL, and the prefix its links go out on. Request
  */
 type MmsCallRequestWritable = {
-  body: SimpleTemplateConfigRequest;
+  body?: SimpleTemplateConfigRequest;
   /**
    * Address of the host that serves this action's links. Every URL in the body goes out as <link_prefix>/<token>. An absolute http or https URL, path allowed, with no query, fragment or trailing slash.
    */
@@ -4973,11 +5012,13 @@ type ActionRequestWritable = {
     tool_call_type: 'aws_lambda_request';
   } & ActionAwsLambdaCallRequestWritable) | ({
     tool_call_type: 'manual_upload';
-  } & ActionManualUploadCallRequest);
+  } & ActionManualUploadCallRequest) | ({
+    tool_call_type: 'run_data_activation_client';
+  } & ActionRunDataActivationClientCallRequestWritable);
   /**
-   * Tool that executes this action
+   * Tool that executes this action. Required for every action type except data_activation, which refuses one: its client carries its own tool.
    */
-  tool_id: string;
+  tool_id?: string | null;
   /**
    * Liquid template that determines when this action executes
    */
@@ -5098,7 +5139,7 @@ type EmailRequestWritable = {
    */
   domain?: string;
   /**
-   * Custom Mailgun API base URL (e.g., https://api.eu.mailgun.net/v3 for EU domains, or a WireMock endpoint for integration tests); leave blank for real Mailgun
+   * Custom provider endpoint; leave blank for the real provider. For SES, the whole request URL (e.g., http://localhost:4566 for MiniStack); blank means https://email.<region>.amazonaws.com. For Mailgun, the API base URL (e.g., https://api.eu.mailgun.net/v3 for EU domains, or a WireMock endpoint for integration tests)
    */
   endpoint_url?: string | null;
   /**
@@ -5794,6 +5835,12 @@ type SftpRequestWritable = {
    */
   user_name: string;
 };
+/**
+ * ActionRunDataActivationClientCallRequest
+ */
+type ActionRunDataActivationClientCallRequestWritable = RunDataActivationClientCallRequest & {
+  tool_call_type: 'run_data_activation_client';
+};
 /**
  * CloudStorageCustomRequest
  *