@alvera-ai/platform-sdk 0.18.2 → 0.19.2-next.g845dfdf

package/.agent/data_activation_clients.md

@@ -164,6 +164,70 @@ Anchor on the empty-render-passes rule, not on the Liquid
 keyword — `{% if ... %}...{% endif %}` and
 `{% unless ... %}...{% endunless %}` are equivalent.
 
+### `rows_from_file_template` says HOW MANY rows, never what is in them
+
+A fetch lands a file in storage. `rows_from_file_template` is a
+Liquid template that turns that file into the list of rows to
+ingest. It may be set on **any** file — the content type decides
+only how the file is DECODED, never whether a template is
+allowed — and a run is never refused for declaring one.
+
+`msg` binds to the decoded **whole file**: one value per file,
+never a row. What it holds depends on how the fetch stored the
+file:
+
+| stored as              | `msg` is                                  |
+|------------------------|-------------------------------------------|
+| `application/json`     | the parsed document                       |
+| `application/x-ndjson` | the list of every parsed line             |
+| `text/csv`             | the list of row maps, keyed by header     |
+| PDF, PNG, JPEG, WebP   | `{ r2_key, content_type }` — a pointer, bytes undecoded |
+
+The template must render a **JSON array**. Liquid renders text,
+so any value has to be serialised on the way out; `to_json` is
+the filter that does it, and there is no inverse — nothing parses
+a JSON string back into a value inside the template.
+
+Three shapes cover nearly everything:
+
+- **one document becomes many rows** —
+  `{{ msg.data | to_json }}`
+- **many rows become fewer** —
+  `{% assign kept = msg | where: "status", "active" %}{{ kept | to_json }}`
+- **a whole file becomes one row** — `[{{ msg | to_json }}]`.
+  The brackets are what make it a list; this is the usual shape
+  for a PDF or an image, where `msg` is already the pointer the
+  contract needs.
+
+**Leave it unset when the file is already the rows.** A
+`sql_query` export, a CSV, and most `sftp` / `s3` bodies land as
+rows already. Unset means take them as they are — the common
+case, and it streams a chunk at a time instead of holding the
+file in memory, which a template cannot do because it has to see
+the whole file at once.
+
+**The template decides how many rows there are; the contract
+decides what is in each one.** A contract runs per row and can
+never change the count, which is the one thing only this
+template can do. Renaming or reshaping fields belongs in the
+contract (`interoperability_contracts.md`), not here.
+
+It runs on `.runManually`, on `.ingestFile`, and on every cron
+fire — every path that fetches a file. It does **not** run on
+`.ingest`, which takes rows inline and has no file to decode.
+
+Extraction happens in a background job, so a template that fails
+never reaches the HTTP response — `.runManually` still returns
+its `batch_id`. The failure surfaces as a `data_activation_logs`
+row you read back through `.logs.list` (§6.4), and in the
+platform's error log under `error_code: rows_template_failed`.
+
+**Renamed.** This field was `response_extractor` until
+2026-09-14; manifests and contracts written against the old name
+need updating. The tool-level `response_extractor` (`tools.md`)
+is a different field doing a different job — it maps a model
+provider's envelope into a canonical result — and keeps its name.
+
 ## 3. Field ownership
 
 **Server-derived (Response-only).** Universal set from
@@ -199,18 +263,17 @@ downstream_connection_ids       optional UUID[] — DACs triggered after this
 filter_config                   optional embed — TemplateConfig; server-pinned
                                   output_schema (enum ["true","false"]). A row-
                                   level filter evaluated per fetched row
-response_extractor              optional embed — TemplateConfig ({ type, body });
-                                  a Liquid template that unwraps a nested API
-                                  envelope into the row array (e.g.
-                                  `{{ msg.data | to_json }}`). Load-bearing for
-                                  `rest_api` fetch clients; see
-                                  `cookbook/subscription-saas.md` §032–035
+rows_from_file_template         optional embed — TemplateConfig ({ type, body });
+                                  a Liquid template that says where the rows are
+                                  inside a fetched file. It may be set on ANY
+                                  file and is never refused — see §2 for what
+                                  `msg` binds to and when to leave it unset
 ```
 
 **Write-only (Request-only).** None — every caller-supplied
 field round-trips on the response (the virtual array
 round-trips under `interoperability_contracts` on response).
-`filter_config` / `response_extractor` come back under the read-only
+`filter_config` / `rows_from_file_template` come back under the read-only
 `SimpleTemplateConfigResponse` shape (their `output_schema` is
 server-pinned and not echoed).
 
@@ -314,7 +377,7 @@ Three run shapes exist, selected by the bound tool's
 All three produce **log rows** observable through
 `api.dataActivationClients.logs.*` (§6.4), and the canonical way
 to **verify** that ingestion worked is the two-step
-dataset-search pattern in §6.5.
+dataset-search pattern in §6.6.
 
 ### 6.1 Inline JSON ingestion — `.ingest`
 
@@ -334,7 +397,7 @@ const { data } = await api.dataActivationClients.ingest(
 The response returns **immediately after enqueueing**, not
 after ingestion completes. To know when the row has actually
 been written, poll the logs (§6.4) or use the verification
-pattern (§6.5).
+pattern (§6.6).
 
 The `batch_id` is the most important field on the response —
 every downstream log row and dataset row carries the same
@@ -471,7 +534,110 @@ merge step has committed the ndjson archive. Use
 `output_files.length > 0` as the "this batch's rows are fully
 durable" signal — not just the presence of the log row.
 
-### 6.5 Verifying ingestion: the two-step dataset search
+### 6.5 Runs subresource — `.batches.list` / `.batches.get`
+
+A **run** is one record; the log rows of §6.4 are one record per
+dataset table that run wrote into. Read the run to answer *"is this
+over, and how did it end"*; read the logs for the per-table detail,
+filtered on the same `batch_id`.
+
+Before this record existed, the only way to ask whether a run had
+finished was to count log rows and guess — which cannot tell a run
+still going from one that produced nothing and never will. A run
+that was skipped or that died looked exactly like a slow one until
+the caller's timeout expired.
+
+```
+batch_id     UUID — the run identifier, the same one `.ingest`,
+                    `.ingestFile` and `.runManually` hand back, and the
+                    one stamped on every per-table log row of this run
+client_id    UUID — the owning activation client
+closed_at    ISO timestamp | null — when the run was attempted and
+                    exhausted. Null while it is still going. It does NOT
+                    mean rows landed and it does NOT mean the archive was
+                    merged — read `status` for the outcome, and only once
+                    this is set.
+status       'processing' | 'succeeded' | 'partial' | 'skipped' | 'failed'
+rows_total   number — source rows enqueued for this run. The run's own
+                    count; each per-table log keeps its own.
+inserted_at  ISO timestamp — when the run started
+```
+
+**`status` means nothing until `closed_at` is set.** A run in flight
+always reads `processing`. Once it is closed:
+
+| status | what happened |
+|---|---|
+| `succeeded` | it ran and nothing was refused |
+| `partial` | it ran and at least one row was refused on the way in; the rows that landed are still there |
+| `skipped` | it ran and there was nothing to do — empty file, every row filtered out, or the client has no contracts |
+| `failed` | it died before writing anything |
+
+```typescript
+// Paginated list of runs for an activation client. Takes the full Flop
+// query (page / page_size / order_by / order_directions / filters —
+// type_naming.md); without it, page 1 only.
+const { data } = await api.dataActivationClients.batches.list(
+  tenantSlug, datalakeSlug, activationClientSlug,
+  { page: 1, page_size: 50, order_by: ['inserted_at'], order_directions: ['desc'] },
+)
+// data.data — array of run records; data.meta — pagination
+
+// Fetch one run by its batch_id.
+const { data: run } = await api.dataActivationClients.batches.get(
+  tenantSlug, datalakeSlug, activationClientSlug, batchId,
+)
+```
+
+> **The fourth argument is the `batch_id`, not the record's `id`.**
+> A run record carries both, and both are UUIDs. The route looks the
+> run up by its `batch_id` — the identifier the ingest handed you — so
+> passing the record's own `id` is a **404**, not a type error.
+
+#### Waiting on a run
+
+This is what the run record is for. Poll until `closed_at` is set,
+then branch on `status` — never poll `status` alone, because a run
+in flight reads `processing` forever and tells you nothing:
+
+```typescript
+const { data: ingest } = await api.dataActivationClients.ingest(
+  tenantSlug, datalakeSlug, activationClientSlug, { data: row },
+)
+
+const deadline = Date.now() + 120_000
+let run
+for (;;) {
+  const { data } = await api.dataActivationClients.batches.get(
+    tenantSlug, datalakeSlug, activationClientSlug, ingest.batch_id,
+  )
+  if (data.closed_at != null) { run = data; break }
+  if (Date.now() > deadline) throw new Error(`run ${ingest.batch_id} never closed`)
+  await new Promise((r) => setTimeout(r, 1_000))
+}
+
+if (run.status === 'failed') {
+  throw new Error(`run ${ingest.batch_id} failed before writing anything`)
+}
+if (run.status === 'skipped') {
+  throw new Error(`run ${ingest.batch_id} had nothing to do — check the row filter and the client's contracts`)
+}
+// 'succeeded' or 'partial' — the run is over and rows were written.
+// For a partial, read the log rows (§6.4) for which table refused what.
+```
+
+A run that failed or was skipped **ends the wait immediately, carrying
+why**. That is the whole difference from counting rows: a blind poll
+spends its full timeout and then reports nothing about the cause.
+
+> **`closed_at` is not the same as "my row is queryable".** It says the
+> run is over. It does not say the archive was merged (that is
+> `output_files` on the log rows, §6.4), and for one specific row it
+> does not replace the landing check in §6.6 — it makes that check a
+> single read after the run is known finished, instead of a guess
+> against a deadline.
+
+### 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
@@ -638,7 +804,7 @@ screen. Pick the mode by which of those two readers you are serving.
    response carries `batch_id` + `jobs_count`, signalling that
    downstream jobs have been enqueued — not that they've
    completed. Poll logs (or use the search verification
-   pattern in §6.5) before treating the row as ingested.
+   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

package/.agent/datalakes.md

@@ -110,7 +110,7 @@ The platform does NOT expose a query API over the archive itself —
 cold reads happen externally so the platform's processes aren't
 responsible for analytical workloads. Live data lives in the
 datalake's Postgres halves (queryable via the dataset search
-two-step pattern in `data_activation_clients.md` §6.5); historical
+two-step pattern in `data_activation_clients.md` §6.6); historical
 data lives in the cloud-storage buckets configured here.
 
 ### Canonical create body

package/.agent/interoperability_contracts.md

@@ -299,7 +299,7 @@ in the datalake and there is nothing to search afterwards. 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.5).
+`batch_id` (see `data_activation_clients.md` §6.6).
 
 ```typescript
 const { data: result } = await api.interoperabilityContracts.run(

package/.agent/mdm.md

@@ -185,6 +185,61 @@ is a 404, not a `'not_verified'`. The distinction matters:
 A consumer that conflates the two will mis-route an identity
 challenge as a missing-record error.
 
+### One label per kind of identifier a subject holds
+
+An identification attaches to a legal entity under a label — its `uri` —
+alongside an `id_type`. The pair `(uri, id_type)` is a **slot** on that
+subject, and a subject holds each slot once. Two identifications under the
+same pair are refused, not merged and not resolved to a winner.
+
+So a subject that carries more than one identifier needs a label per kind.
+Jane, from a Shopify store, with an email and a phone:
+
+```json
+"identifications": [
+  { "id_type": "digital_identifier",
+    "uri": "shopify",
+    "id_number": "jane@example.com" },
+  { "id_type": "digital_identifier",
+    "uri": "shopify::phone",
+    "id_number": "+15551234" }
+]
+```
+
+Written with `"uri": "shopify"` on both, the second is refused — the database
+enforces it as `legal_entity_identifications_entity_uri_type_uk`.
+
+The convention: the bare source identifies the **subject**; anything else the
+subject carries gets its own label beneath it.
+
+**Do not re-label identifications that already exist.** Changing the `uri` on a
+recipe that has already run sends the next ingest to a DIFFERENT slot, which
+adds a second identification rather than updating the first — the original is
+orphaned, silently, and both then answer to the same person.
+
+### What a resolve does to the slots it does not name
+
+A resolve speaks only about the slots it names:
+
+| the slot you send | what happens |
+|---|---|
+| named, already filled | **overwritten** |
+| named, empty | **added** |
+| **not mentioned** | **kept, untouched** |
+
+The third row is the one worth designing around, and the one nothing else
+states. Several lanes can each resolve the same subject knowing only their own
+identifiers, without destroying each other's work: a marketing lane sending
+only an email and a billing lane sending only a phone both survive, in either
+order.
+
+Two limits that follow from the same rule:
+
+- **A slot cannot be emptied through a resolve.** Omitting it means "leave it";
+  there is no value that means "remove it".
+- **Two values under one `(uri, id_type)` in a single payload are refused**
+  rather than resolved to a winner — the platform does not pick.
+
 ## 3. Field ownership
 
 **Server-derived (Response-only).**
@@ -284,7 +339,7 @@ SDK surface:
 
 Today there is no `.list`, `.get`, or `.metadata` on the MDM
 namespace — subjects themselves are queried through the dataset
-search surface (see `data_activation_clients.md` §6.5), not
+search surface (see `data_activation_clients.md` §6.6), not
 through `api.mdm`.
 
 ## 6. Gotchas

package/.agent/mock-services.md

@@ -95,21 +95,21 @@ flowchart TD
     end
 ```
 
-**It lives in this repo**, at `cloudflare-workers/mock/`. Deploy from a normal checkout:
+**It lives in this repo**, at `cloudflare/workers/mock/`. Deploy from a normal checkout:
 
 ```bash
-cd cloudflare-workers/mock && wrangler deploy
+cd cloudflare/workers/mock && wrangler deploy
 ```
 
 The single line that makes this work without a vendored copy of the corpus:
 
 ```jsonc
-"image_build_context": ".."
+"image_build_context": "../../.."
 ```
 
 That sets the Docker build context to the repo root, so the Dockerfile copies
 `wm_mappings/` and `wm_response_files/` from where they already live. Without it
-the context is `cloudflare-workers/mock/` and the corpus would have to be duplicated there —
+the context is `cloudflare/workers/mock/` and the corpus would have to be duplicated there —
 two directories that look identical until they quietly aren't.
 
 ### There is no authentication

package/.agent/workflows.md

@@ -492,6 +492,73 @@ actions                      required array — inline; replace-on-PUT
 workflow_ai_agents          optional array — inline; replace-on-PUT (see §3)
 ```
 
+Caller-supplied fields **inside each `context_datasets[*]`** row:
+
+```
+dataset_type                 required string — CLOSED ENUM, not free text. An
+                                              arbitrary value 422s at apply and
+                                              the error enumerates the allowed
+                                              types
+generic_table_id             required UUID when dataset_type == 'generic_table';
+                                              omit otherwise. NOT the same field
+                                              as the workflow's own
+                                              `generic_table_id` one level up
+where_clause                 optional string — Liquid, max 10_000 chars (see
+                                              below for what it can reach, and
+                                              which tier it runs against)
+limit                        optional int   — must be positive
+position                     optional int   — default 0
+```
+
+### Reading what a context query returned
+
+`additional_context.<dataset_type>` — the `dataset_type` string **literally**,
+not the table name and not a slug. A `document` context is read at
+`additional_context.document`.
+
+Do not confuse this with the AI-agent form documented above
+(`additional_context.<agent_slug>.<field>`): an agent is keyed by its slug, a
+context dataset by its type.
+
+### ⚠ Two context datasets of the same `dataset_type` silently overwrite
+
+The loader accumulates them into a map keyed by `dataset_type`, so declaring
+two of the same type leaves **only the last one**. There is no error and no
+warning — the workflow runs happily against the wrong context. If you need two
+slices of one type, express it as one query with a wider `where_clause`.
+
+### The `where_clause` reaches the row differently than the filter does
+
+This asymmetry is the easiest thing here to get wrong:
+
+```
+where clause   {{ <dataset_type>.field }}      e.g. {{ generic_table.external_client_id }}
+filter         {{ event_dataset.field }}       the SAME row, different accessor
+```
+
+That makes three conventions for "the current row" across this corpus — the
+third being `msg.row.x` in an interoperability filter versus `msg.x` in its
+transform. Nothing about a name tells you which one you are in; the surface you
+are authoring does.
+
+### Context queries run against the REGULATED tier
+
+The loader reads context in regulated mode, so a `where_clause` must name the
+**regulated** table alias (e.g. `regulated_alvera_custom_unsubscribe_list`),
+not the unregulated name. This changes every where clause you write, and a
+clause written against the unregulated name finds nothing rather than failing
+loudly.
+
+### `context_datasets` cannot be cleared by omission
+
+It is a **required, replace-on-PUT array**. Dropping the block from a manifest
+does not clear it: the server retains what was last deployed, the rendered and
+deployed checksums never converge, and every subsequent `plan` reports drift on
+a config that was just applied. Send an explicit `[]` to mean "no context".
+
+Same class as the `assume_role_external_id` convergence note — an omission that
+reads as "leave it alone" on the wire and as "remove it" in the author's head.
+
 Caller-supplied fields **inside each `actions[*]`** row:
 
 ```
@@ -647,7 +714,7 @@ an error to retry.
 tables. For a **platform dataset** the server assigns the alias
 (`le` legal entities, `m` messages, `al` action logs, `d` documents,
 `bo` beneficial owners — same scheme as `data_activation_clients.md`
-§6.5), and `id` is ambiguous across the base query's joins, so always
+§6.6), and `id` is ambiguous across the base query's joins, so always
 prefix it: `le.id`.
 
 For a **generic-table** workflow there is no alias — the run selects

package/dist/index.d.mts

@@ -567,9 +567,9 @@ type DataActivationClientLogResponse = {
    */
   rows_ingested?: number;
   /**
-   * `failed` when the batch died before enqueueing any row — the fetch itself errored, and `rows_ingested` and `input_files` are 0/[] on such a row. `partial` when the batch ran and at least one row was refused on the way in; the rows that landed are still there. Read `error` for the reason in both cases.
+   * `processing` from the moment the slice is enqueued until the batch finishes — the column has no default, so this is written, not assumed. `succeeded` is written once by the batch callback, and only over `processing`. `failed` when the batch died before enqueueing any row — the fetch or the enqueue itself errored, and `rows_ingested` and `input_files` are 0/[] on such a row. `partial` when the batch ran and at least one row was refused on the way in; the rows that landed are still there. Read `error` for the reason in the last two.
    */
-  status?: 'succeeded' | 'partial' | 'failed';
+  status?: 'processing' | 'succeeded' | 'partial' | 'failed';
   readonly updated_at?: string;
 };
 /**
@@ -2150,6 +2150,42 @@ type AiAgentInvokeRequest = {
     [key: string]: unknown;
   };
 };
+/**
+ * DataActivationClientBatchResponse
+ *
+ * One record per run. A run fans out into one `DataActivationClientLog` per dataset table it writes into; this is the run itself. To wait on a run, read `closed_at` here rather than reconstructing it from those logs — it is set exactly once, however the run ended.
+ */
+type DataActivationClientBatchResponse = {
+  /**
+   * Run identifier, stamped on every Oban job and every per-table log row of this run
+   */
+  batch_id: string;
+  /**
+   * Owning Data Activation Client ID
+   */
+  readonly client_id: string;
+  /**
+   * When the run was attempted and exhausted. Null while it is still going. It does not mean rows landed and it does not mean the archive was merged — read `status` for the outcome, and only once this is set.
+   */
+  readonly closed_at?: string | null;
+  /**
+   * Run record ID
+   */
+  readonly id?: string;
+  /**
+   * When the run started
+   */
+  readonly inserted_at?: string;
+  /**
+   * Source rows enqueued for this run. The run's own count; each per-table log keeps its own.
+   */
+  rows_total?: number;
+  /**
+   * How the run ended. **It means nothing until `closed_at` is set** — a run still in flight always reads `processing`. `failed` when the run died before writing anything; `partial` when it ran and at least one row was refused on the way in; `skipped` when it ran and there was nothing to do, because the file was empty, every row was filtered out, or the client has no contracts.
+   */
+  status?: 'processing' | 'succeeded' | 'partial' | 'skipped' | 'failed';
+  readonly updated_at?: string;
+};
 /**
  * AdvancedMigrationResponse
  *
@@ -3445,6 +3481,18 @@ type SqsResponse = {
    */
   region: string;
 };
+/**
+ * DataActivationClientBatchListResponse
+ *
+ * Paginated list of data activation client runs
+ */
+type DataActivationClientBatchListResponse = {
+  /**
+   * List of data activation client runs
+   */
+  data: Array<DataActivationClientBatchResponse>;
+  meta: PaginationMeta;
+};
 /**
  * PaginationMeta
  *
@@ -3766,11 +3814,11 @@ type DataActivationClientResponse = {
    * DAC name
    */
   name: string;
-  response_extractor?: SimpleTemplateConfigResponse | null;
   /**
    * Optional row-level Liquid pre-filter. Renders to empty/whitespace → row passes; any non-empty trimmed render → row is skipped (rendered string is the skip reason). Nil/empty body = no filter. Same semantics as InteroperabilityContract.filter_template.
    */
   row_filter?: string | null;
+  rows_from_file_template?: SimpleTemplateConfigResponse | null;
   /**
    * URL-friendly slug (derived from name on insert; immutable)
    */
@@ -5967,11 +6015,11 @@ type DataActivationClientRequestWritable = {
    * DAC name
    */
   name: string;
-  response_extractor?: SimpleTemplateConfigRequest;
   /**
    * Optional row-level Liquid pre-filter. Renders to empty/whitespace → row passes; any non-empty trimmed render → row is skipped (rendered string is the skip reason). Nil/empty body = no filter. Same semantics as InteroperabilityContract.filter_template.
    */
   row_filter?: string | null;
+  rows_from_file_template?: SimpleTemplateConfigRequest | null;
   tool_call: ({
     tool_call_type: 'restapi_request';
   } & DataActivationClientRestCallRequestWritable) | ({
@@ -6593,6 +6641,59 @@ type PlatformApiAdvancedMigrationControllerIndexData = {
   };
   url: '/api/v1/tenants/{tenant_slug}/datalakes/{datalake_slug}/advanced-migrations';
 };
+type PlatformApiDataActivationClientControllerBatchesIndexData = {
+  body?: never;
+  path: {
+    /**
+     * Tenant slug
+     */
+    tenant_slug: string;
+    /**
+     * Datalake slug
+     */
+    datalake_slug: string;
+    /**
+     * Data Activation Client slug
+     */
+    slug: string;
+  };
+  query?: {
+    /**
+     * Items per page (1-100). Defaults to the resource's Flop default when omitted.
+     */
+    page_size?: number;
+    /**
+     * Page number (1-indexed). Defaults to 1 when omitted.
+     */
+    page?: number;
+    /**
+     * Fields to sort by, in order of precedence. Must appear in the resource schema's Flop `sortable:` list — unknown fields return 422.
+     */
+    order_by?: Array<string>;
+    /**
+     * Sort direction(s), pair-wise with `order_by`. `asc` or `desc`. Defaults to `asc` per unpaired `order_by` entry.
+     */
+    order_directions?: Array<'asc' | 'desc'>;
+    /**
+     * Flop-native filter array. URL shape: `?filters[][field]=status&filters[][op]=%3D%3D&filters[][value]=pending` (empty brackets — consecutive `[]` entries group into one filter object per element; indexed brackets parse as a map and fail the array cast with 422). `op` is the symbol, percent-encoded — `%3D%3D` for `==`, `%3E%3D` for `>=` — not a word like `equal`; anything outside the enum above is a 422 before the request reaches Flop. Omit `op` entirely for equality. Unknown fields return 422 via Flop validation at the context layer.
+     */
+    filters?: Array<{
+      /**
+       * Filterable field name (must be in the resource's `filterable:`)
+       */
+      field: string;
+      /**
+       * Comparison operator. Defaults to `==` when omitted.
+       */
+      op?: '==' | '!=' | '<' | '<=' | '>' | '>=' | 'empty' | 'not_empty' | 'like' | 'ilike' | 'like_and' | 'like_or' | 'ilike_and' | 'ilike_or' | 'in' | 'not_in' | 'contains' | 'not_contains';
+      /**
+       * Filter value — shape depends on `field` and `op`.
+       */
+      value: unknown;
+    }>;
+  };
+  url: '/api/v1/tenants/{tenant_slug}/datalakes/{datalake_slug}/data-activation-clients/{slug}/batches';
+};
 type PlatformApiAiAgentControllerIndexData = {
   body?: never;
   path: {
@@ -8353,6 +8454,18 @@ declare function _buildApi(myClient: Client): {
         response: Response;
       }>;
     };
+    batches: {
+      list: (tenantSlug: string, datalakeSlug: string, slug: string, query?: PlatformApiDataActivationClientControllerBatchesIndexData["query"]) => Promise<{
+        data: DataActivationClientBatchListResponse;
+        request: Request;
+        response: Response;
+      }>;
+      get: (tenantSlug: string, datalakeSlug: string, slug: string, batchId: string) => Promise<{
+        data: DataActivationClientBatchResponse;
+        request: Request;
+        response: Response;
+      }>;
+    };
   };
   interoperabilityContracts: {
     list: (tenantSlug: string, datalakeSlug: string, query?: PlatformApiInteroperabilityContractControllerIndexData["query"]) => Promise<{
@@ -8535,5 +8648,5 @@ declare function _buildApi(myClient: Client): {
 //#region src/index.d.ts
 declare function isEnvironmentName(name: string): name is EnvironmentName;
 //#endregion
-export { type ActionStatusUpdaterCloudWatchQueryRequest, type ActionStatusUpdaterRequestWritable, type ActionStatusUpdaterResponse, type ActionStatusUpdaterRestCallRequest, ActionType, type AdvancedMigrationListResponse, type AdvancedMigrationRequest, type AdvancedMigrationResponse, type AgenticWorkflowListResponse, type AgenticWorkflowRequestWritable, type AgenticWorkflowResponse, type AiAgentRequestWritable, type AiAgentResponse, type AlveraApiError, type AlveraClient, type ApiConfig, type ApiDebugConfig, type BatchLogListResponse, type BatchLogResponse, type ConnectedAppListResponse, type ConnectedAppRequestWritable, type ConnectedAppResponse, type CreateActionStatusUpdaterRequest, type CreateAiAgentRequest, type CreateGenericTableRequest, type CreateSessionParams, DEFAULT_ENVIRONMENT, type DataActivationClientListResponse, type DataActivationClientLogListResponse, type DataActivationClientLogResponse, type DataActivationClientRequestWritable, type DataActivationClientResponse, type DataSourceRequest, type DataSourceRequestWritable, type DataSourceResponse, type DatalakeRequestWritable, type DatalakeResponse, type DatasetMetadataOptions, type DatasetSearchOptions, type DatasetSearchResponse, type DerivedLakeTablesResponse, type DownloadUrlResponse, ENVIRONMENTS, type EnvironmentName, type ErrorResponse, type ExecuteActionRequest, type ExecuteActionResponse, type ExecuteSqlMeta, type ExecuteSqlRequest, type ExecuteSqlResponse, type GenericTableColumnRequest, type GenericTableColumnResponse, type GenericTableResponse, type IngestFileRequest, type IngestRequest, type InteroperabilityContractAiAgentRequestWritable, type InteroperabilityContractListResponse, type InteroperabilityContractRequestWritable, type InteroperabilityContractResponse, type InteroperabilityRunRequest, type InteroperabilityRunResponse, type MdmVerifyRequest, type MdmVerifyResponse, type PaginationMeta, type PlatformApi, type ResolvePageRequest, type ResyncTableRequest, type ResyncTableResponse, type RunManuallyRequestWritable, type RunManuallyResponse, type RunWorkflowRequest, type RunWorkflowResponse, type SessionResponse, type SessionResult, type SyncRoutesResponse, type TemplateConfig, type TenantListResponse, type TenantResponse, type TextToSqlRequest, type TextToSqlResponse, ToolIntent, type ToolListResponse, type ToolRequest, type ToolRequestWritable, type ToolResponse, type ToolTwilioRequest, type ToolTwilioRequestWritable, type ToolTwilioResponse, type TwilioRequest, type TwilioRequestWritable, type TwilioResponse, type UpdatePageRequest, type UploadLinkRequest, type UploadLinkResponse, type WorkflowAiAgentRequestWritable, type WorkflowLogListResponse, type WorkflowLogResponse, type WorkflowRunListResponse, type WorkflowRunResponse, createBootstrapSession, createIsolatedPlatformApi, createPlatformApi, createSession, isEnvironmentName, revokeSession };
+export { type ActionStatusUpdaterCloudWatchQueryRequest, type ActionStatusUpdaterRequestWritable, type ActionStatusUpdaterResponse, type ActionStatusUpdaterRestCallRequest, ActionType, type AdvancedMigrationListResponse, type AdvancedMigrationRequest, type AdvancedMigrationResponse, type AgenticWorkflowListResponse, type AgenticWorkflowRequestWritable, type AgenticWorkflowResponse, type AiAgentRequestWritable, type AiAgentResponse, type AlveraApiError, type AlveraClient, type ApiConfig, type ApiDebugConfig, type BatchLogListResponse, type BatchLogResponse, type ConnectedAppListResponse, type ConnectedAppRequestWritable, type ConnectedAppResponse, type CreateActionStatusUpdaterRequest, type CreateAiAgentRequest, type CreateGenericTableRequest, type CreateSessionParams, DEFAULT_ENVIRONMENT, type DataActivationClientBatchListResponse, type DataActivationClientBatchResponse, type DataActivationClientListResponse, type DataActivationClientLogListResponse, type DataActivationClientLogResponse, type DataActivationClientRequestWritable, type DataActivationClientResponse, type DataSourceRequest, type DataSourceRequestWritable, type DataSourceResponse, type DatalakeRequestWritable, type DatalakeResponse, type DatasetMetadataOptions, type DatasetSearchOptions, type DatasetSearchResponse, type DerivedLakeTablesResponse, type DownloadUrlResponse, ENVIRONMENTS, type EnvironmentName, type ErrorResponse, type ExecuteActionRequest, type ExecuteActionResponse, type ExecuteSqlMeta, type ExecuteSqlRequest, type ExecuteSqlResponse, type GenericTableColumnRequest, type GenericTableColumnResponse, type GenericTableResponse, type IngestFileRequest, type IngestRequest, type InteroperabilityContractAiAgentRequestWritable, type InteroperabilityContractListResponse, type InteroperabilityContractRequestWritable, type InteroperabilityContractResponse, type InteroperabilityRunRequest, type InteroperabilityRunResponse, type MdmVerifyRequest, type MdmVerifyResponse, type PaginationMeta, type PlatformApi, type ResolvePageRequest, type ResyncTableRequest, type ResyncTableResponse, type RunManuallyRequestWritable, type RunManuallyResponse, type RunWorkflowRequest, type RunWorkflowResponse, type SessionResponse, type SessionResult, type SyncRoutesResponse, type TemplateConfig, type TenantListResponse, type TenantResponse, type TextToSqlRequest, type TextToSqlResponse, ToolIntent, type ToolListResponse, type ToolRequest, type ToolRequestWritable, type ToolResponse, type ToolTwilioRequest, type ToolTwilioRequestWritable, type ToolTwilioResponse, type TwilioRequest, type TwilioRequestWritable, type TwilioResponse, type UpdatePageRequest, type UploadLinkRequest, type UploadLinkResponse, type WorkflowAiAgentRequestWritable, type WorkflowLogListResponse, type WorkflowLogResponse, type WorkflowRunListResponse, type WorkflowRunResponse, createBootstrapSession, createIsolatedPlatformApi, createPlatformApi, createSession, isEnvironmentName, revokeSession };
 //# sourceMappingURL=index.d.mts.map