Previous value: -"One of:\n- 'status': Get full queue details (pending/sent/failed items with names and times).\n  The `pending_items` / `pending_approval_items` / `failed_items` lists cap at 50\n  each, each with a matching `*_truncated` flag — when a list's flag is True, more\n  rows exist past this page; pass `offset` (offset += 50) to read them. Each\n  `failed_items` row carries `last_error`, the reason that send failed — read it to\n  answer \"why wasn't X sent?\". `pending_approval_items` rows also carry `last_error`\n  when the row was held for a reason beyond plain approval gating (e.g. the\n  resolver's name-mismatch hold). Queued post comments and reactions carry `post_url`\n  and a `post_text` excerpt of the post the action targets, so you can tell which\n  post a queued comment is on; `post_text_truncated` True means the target post ran\n  longer than the excerpt shown. All four lists share one field shape; a\n  `resolving_items` row (profile not yet resolved) has a blank `target_provider_id`\n  and its `message` is the copy that will send once it resolves — edit or cancel it\n  by its `target_identifier`. Every `pending_items` / `resolving_items` row carries\n  `projected_send_day` + `projected_send_time` (a resolving row's is its projected\n  lookup time, or its projected send time once it's a resolve-then-send) and a\n  `queue_position` — the row's place in the one ordered lookup+send timeline, so the\n  two lists interleave into what actually fires next. The top-level `send_forecast`\n  is account-wide: `days` counts queued sends per day and `eta_date` is the day the\n  last one goes out. A `resolve` row in `resolving_items` queues no invite itself, so\n  `estimated_invites` counts per day the connection request each is expected to lead\n  to, and `invites_sent_by` is the day the last connection request goes out, queued\n  or estimated (null when none is due or one won't fit in the forecast window) —\n  read it to answer \"when will all my invites be sent?\". The top-level `cancelled_by_kind` maps each cancel\n  cause to its count (`recipient_replied`, `task_deleted`, `auto_shelved`, …;\n  pre-taxonomy rows under `unknown`) — read it to answer \"how much outreach was\n  cancelled, and why?\".\n- 'update': Update a queued item's message text. Name the item by\n  target_provider_id (a pending row's pid) OR, for a resolving row that has no\n  pid yet, by target_identifier (its URL/slug, shown on the row). Use this to\n  edit a queued message — including on resolving rows, which still hold the\n  message that will send once their profile resolves. When a target has more\n  than one queued action — a post with both a comment and a reaction, or a\n  person with a connection request and a follow — also pass action_type to name\n  which one to edit. A draft on a step running an A/B test carries `ab_version`\n  ('A', 'B', or 'left_out' when its send won't count) on its status row and in\n  this action's result; updating one takes ab_version too — the version the\n  edited draft reads as — or ab_version alone to re-file it unedited.\n- 'approve': Send authorization belongs to the user, so this action needs a\n  message that arrived after the drafts were queued and explicitly says to\n  approve or send them. A message from before the drafts existed cannot\n  authorize them — a request to review them, to approve them later, or to be\n  able to approve from chat means: report that the queue is awaiting approval\n  and end your turn; the user's next message decides. Once authorized, this\n  moves pending_approval items to 'pending'; they then send in queue order at\n  your account's pace. If\n  target_provider_id is given, approve only that item. Otherwise approve ALL\n  pending_approval items (optionally filtered by action_type).\n  Only touches items already awaiting approval — it does NOT run pending profile\n  lookups or pre-approve resolving rows (those aren't in the approvals UI, so\n  nobody has reviewed them; they resolve on their own schedule and, if the\n  user's settings gate the action, surface for approval once resolved).\n  From account-level chat an approve-all is rejected unless agent_id names the\n  campaign — it must not fire every campaign's drafts into sending at once.\n- 'cancel': Cancel a queued item. Pass target_provider_id to cancel that one\n  person or post — every queued action for them — or target_identifier to cancel\n  a resolving row that has no pid yet. To cancel the ENTIRE pending\n  queue — which drops drafts the user\n  already approved — you must pass\n  cancel_all=True; an unscoped cancel without it is rejected (an action_type\n  or node_id filter alone is still a bulk cancel and also needs cancel_all=True).\n  Narrow a cancel_all to one flow stage with node_id (e.g. restart only the m2\n  messages without touching m3) — the only way to separate two stages that share\n  an action_type. From account-level chat a cancel_all is rejected unless agent_id\n  names the campaign to cancel — it must not clear every campaign's queue at once.\n- 'pause': Pause the queue (stops sending, keeps items queued). Pass resume_at\n  to schedule an automatic resume (\"pause while I'm on vacation, resume July 20\");\n  without it the pause is indefinite and only an explicit 'resume' restarts sending.\n- 'resume': Resume the queue (pending items drain in queue order at your account's pace)"New value: +"One of:\n- 'status': Get full queue details (pending/sent/failed items with names and times).\n  The `pending_items` / `pending_approval_items` / `failed_items` lists cap at 50\n  each, each with a matching `*_truncated` flag — when a list's flag is True, more\n  rows exist past this page; pass `offset` (offset += 50) to read them. Each\n  `failed_items` row carries `last_error`, the reason that send failed — read it to\n  answer \"why wasn't X sent?\". `pending_approval_items` rows carry `hold_reason`\n  when the row was held for a reason beyond plain approval gating (e.g. the\n  resolver's name-mismatch hold, or a [[slot]] the user has to fill in). Queued post\n  comments and reactions carry `post_url` and a `post_text` excerpt of the post the\n  action targets, so you can tell which\n  post a queued comment is on; `post_text_truncated` True means the target post ran\n  longer than the excerpt shown. All four lists share one field shape; a\n  `resolving_items` row (profile not yet resolved) has a blank `target_provider_id`\n  and its `message` is the copy that will send once it resolves — edit or cancel it\n  by its `target_identifier`. Every `pending_items` / `resolving_items` row carries\n  `projected_send_day` + `projected_send_time` (a resolving row's is its projected\n  lookup time, or its projected send time once it's a resolve-then-send) and a\n  `queue_position` — the row's place in the one ordered lookup+send timeline, so the\n  two lists interleave into what actually fires next. The top-level `send_forecast`\n  is account-wide: `days` counts queued sends per day and `eta_date` is the day the\n  last one goes out. A `resolve` row in `resolving_items` queues no invite itself, so\n  `estimated_invites` counts per day the connection request each is expected to lead\n  to, and `invites_sent_by` is the day the last connection request goes out, queued\n  or estimated (null when none is due or one won't fit in the forecast window) —\n  read it to answer \"when will all my invites be sent?\". The top-level `cancelled_by_kind` maps each cancel\n  cause to its count (`recipient_replied`, `task_deleted`, `auto_shelved`, …;\n  pre-taxonomy rows under `unknown`) — read it to answer \"how much outreach was\n  cancelled, and why?\".\n- 'update': Update a queued item's message text. Name the item by\n  target_provider_id (a pending row's pid) OR, for a resolving row that has no\n  pid yet, by target_identifier (its URL/slug, shown on the row). Use this to\n  edit a queued message — including on resolving rows, which still hold the\n  message that will send once their profile resolves. When a target has more\n  than one queued action — a post with both a comment and a reaction, or a\n  person with a connection request and a follow — also pass action_type to name\n  which one to edit. A draft on a step running an A/B test carries `ab_version`\n  ('A', 'B', or 'left_out' when its send won't count) on its status row and in\n  this action's result; updating one takes ab_version too — the version the\n  edited draft reads as — or ab_version alone to re-file it unedited.\n- 'approve': Send authorization belongs to the user, so this action needs a\n  message that arrived after the drafts were queued and explicitly says to\n  approve or send them. A message from before the drafts existed cannot\n  authorize them — a request to review them, to approve them later, or to be\n  able to approve from chat means: report that the queue is awaiting approval\n  and end your turn; the user's next message decides. Once authorized, this\n  moves pending_approval items to 'pending'; they then send in queue order at\n  your account's pace. If\n  target_provider_id is given, approve only that item. Otherwise approve ALL\n  pending_approval items (optionally filtered by action_type). A connection\n  request, message or InMail whose text still holds a [[slot]] for the user to fill\n  in stays awaiting approval and comes back in `still_held` with the slot to fill:\n  tell the user, or fill it with 'update' once they give you the wording.\n  Only touches items already awaiting approval — it does NOT run pending profile\n  lookups or pre-approve resolving rows (those aren't in the approvals UI, so\n  nobody has reviewed them; they resolve on their own schedule and, if the\n  user's settings gate the action, surface for approval once resolved).\n  From account-level chat an approve-all is rejected unless agent_id names the\n  campaign — it must not fire every campaign's drafts into sending at once.\n- 'cancel': Cancel a queued item. Pass target_provider_id to cancel that one\n  person or post — every queued action for them — or target_identifier to cancel\n  a resolving row that has no pid yet. To cancel the ENTIRE pending\n  queue — which drops drafts the user\n  already approved — you must pass\n  cancel_all=True; an unscoped cancel without it is rejected (an action_type\n  or node_id filter alone is still a bulk cancel and also needs cancel_all=True).\n  Narrow a cancel_all to one flow stage with node_id (e.g. restart only the m2\n  messages without touching m3) — the only way to separate two stages that share\n  an action_type. From account-level chat a cancel_all is rejected unless agent_id\n  names the campaign to cancel — it must not clear every campaign's queue at once.\n- 'pause': Pause the queue (stops sending, keeps items queued). Not available\n  on a teammate's behalf; approve, cancel, or update their items instead. Pass\n  resume_at to schedule an automatic resume (\"pause while I'm on vacation, resume\n  July 20\"); without it the pause is indefinite and only an explicit 'resume'\n  restarts sending.\n- 'resume': Resume the queue (pending items drain in queue order at your account's pace).\n  Not available on a teammate's behalf; approve, cancel, or update their items instead."

Previous value: -"For 'cancel' and 'approve' — scope a bulk cancel_all / approve-all to one\n    campaign's queue. Required from account-level chat (no active agent), where an\n    unscoped bulk cancel or approve is rejected; call list_agents to get the id."New value: +"For 'cancel' and 'approve' — scope a bulk cancel_all / approve-all to one\n    campaign's queue. Required from account-level chat (no active agent) and in any\n    call with on_behalf_of, where an unscoped bulk cancel or approve is rejected; call\n    list_agents to get the id (list_team_shared_agents for a teammate's campaigns)."

Previous value: -"Act on a consented teammate's queue instead of your own — pass\ntheir email. Covers approve / cancel / update / status; pause and resume\n(account-wide controls) are not available on a teammate's behalf. A bulk\napprove-all / cancel_all must name one of the teammate's campaigns via\nagent_id. Gated on that teammate's act-on-behalf setting; a teammate who\nhasn't granted it is rejected. Omit for your own.\nOr pass an agency client's email, from list_agency_clients, to run the call in that client's account, where none of the teammate limits above apply."New value: +"A teammate's email (one with team actions turned on), or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."

Previous value: -"One of:\n- 'status': Get full queue details (pending/sent/failed items with names and times).\n  The `pending_items` / `pending_approval_items` / `failed_items` lists cap at 50\n  each, each with a matching `*_truncated` flag — when a list's flag is True, more\n  rows exist past this page; pass `offset` (offset += 50) to read them. Each\n  `failed_items` row carries `last_error`, the reason that send failed — read it to\n  answer \"why wasn't X sent?\". `pending_approval_items` rows also carry `last_error`\n  when the row was held for a reason beyond plain approval gating (e.g. the\n  resolver's name-mismatch hold). Queued post comments and reactions carry `post_url`\n  and a `post_text` excerpt of the post the action targets, so you can tell which\n  post a queued comment is on; `post_text_truncated` True means the target post ran\n  longer than the excerpt shown. All four lists share one field shape; a\n  `resolving_items` row (profile not yet resolved) has a blank `target_provider_id`\n  and its `message` is the copy that will send once it resolves — edit or cancel it\n  by its `target_identifier`. Every `pending_items` / `resolving_items` row carries\n  `projected_send_day` + `projected_send_time` (a resolving row's is its projected\n  lookup time, or its projected send time once it's a resolve-then-send) and a\n  `queue_position` — the row's place in the one ordered lookup+send timeline, so the\n  two lists interleave into what actually fires next. The top-level `cancelled_by_kind` maps each cancel\n  cause to its count (`recipient_replied`, `task_deleted`, `auto_shelved`, …;\n  pre-taxonomy rows under `unknown`) — read it to answer \"how much outreach was\n  cancelled, and why?\".\n- 'update': Update a queued item's message text. Name the item by\n  target_provider_id (a pending row's pid) OR, for a resolving row that has no\n  pid yet, by target_identifier (its URL/slug, shown on the row). Use this to\n  edit a queued message — including on resolving rows, which still hold the\n  message that will send once their profile resolves. When a target has more\n  than one queued action — a post with both a comment and a reaction, or a\n  person with a connection request and a follow — also pass action_type to name\n  which one to edit. A draft on a step running an A/B test carries `ab_version`\n  ('A', 'B', or 'left_out' when its send won't count) on its status row and in\n  this action's result; updating one takes ab_version too — the version the\n  edited draft reads as — or ab_version alone to re-file it unedited.\n- 'approve': Send authorization belongs to the user, so this action needs a\n  message that arrived after the drafts were queued and explicitly says to\n  approve or send them. A message from before the drafts existed cannot\n  authorize them — a request to review them, to approve them later, or to be\n  able to approve from chat means: report that the queue is awaiting approval\n  and end your turn; the user's next message decides. Once authorized, this\n  moves pending_approval items to 'pending'; they then send in queue order at\n  your account's pace. If\n  target_provider_id is given, approve only that item. Otherwise approve ALL\n  pending_approval items (optionally filtered by action_type).\n  Only touches items already awaiting approval — it does NOT run pending profile\n  lookups or pre-approve resolving rows (those aren't in the approvals UI, so\n  nobody has reviewed them; they resolve on their own schedule and, if the\n  user's settings gate the action, surface for approval once resolved).\n  From account-level chat an approve-all is rejected unless agent_id names the\n  campaign — it must not fire every campaign's drafts into sending at once.\n- 'cancel': Cancel a queued item. Pass target_provider_id to cancel that one\n  person or post — every queued action for them — or target_identifier to cancel\n  a resolving row that has no pid yet. To cancel the ENTIRE pending\n  queue — which drops drafts the user\n  already approved — you must pass\n  cancel_all=True; an unscoped cancel without it is rejected (an action_type\n  or node_id filter alone is still a bulk cancel and also needs cancel_all=True).\n  Narrow a cancel_all to one flow stage with node_id (e.g. restart only the m2\n  messages without touching m3) — the only way to separate two stages that share\n  an action_type. From account-level chat a cancel_all is rejected unless agent_id\n  names the campaign to cancel — it must not clear every campaign's queue at once.\n- 'pause': Pause the queue (stops sending, keeps items queued). Pass resume_at\n  to schedule an automatic resume (\"pause while I'm on vacation, resume July 20\");\n  without it the pause is indefinite and only an explicit 'resume' restarts sending.\n- 'resume': Resume the queue (pending items drain in queue order at your account's pace)"New value: +"One of:\n- 'status': Get full queue details (pending/sent/failed items with names and times).\n  The `pending_items` / `pending_approval_items` / `failed_items` lists cap at 50\n  each, each with a matching `*_truncated` flag — when a list's flag is True, more\n  rows exist past this page; pass `offset` (offset += 50) to read them. Each\n  `failed_items` row carries `last_error`, the reason that send failed — read it to\n  answer \"why wasn't X sent?\". `pending_approval_items` rows also carry `last_error`\n  when the row was held for a reason beyond plain approval gating (e.g. the\n  resolver's name-mismatch hold). Queued post comments and reactions carry `post_url`\n  and a `post_text` excerpt of the post the action targets, so you can tell which\n  post a queued comment is on; `post_text_truncated` True means the target post ran\n  longer than the excerpt shown. All four lists share one field shape; a\n  `resolving_items` row (profile not yet resolved) has a blank `target_provider_id`\n  and its `message` is the copy that will send once it resolves — edit or cancel it\n  by its `target_identifier`. Every `pending_items` / `resolving_items` row carries\n  `projected_send_day` + `projected_send_time` (a resolving row's is its projected\n  lookup time, or its projected send time once it's a resolve-then-send) and a\n  `queue_position` — the row's place in the one ordered lookup+send timeline, so the\n  two lists interleave into what actually fires next. The top-level `send_forecast`\n  is account-wide: `days` counts queued sends per day and `eta_date` is the day the\n  last one goes out. A `resolve` row in `resolving_items` queues no invite itself, so\n  `estimated_invites` counts per day the connection request each is expected to lead\n  to, and `invites_sent_by` is the day the last connection request goes out, queued\n  or estimated (null when none is due or one won't fit in the forecast window) —\n  read it to answer \"when will all my invites be sent?\". The top-level `cancelled_by_kind` maps each cancel\n  cause to its count (`recipient_replied`, `task_deleted`, `auto_shelved`, …;\n  pre-taxonomy rows under `unknown`) — read it to answer \"how much outreach was\n  cancelled, and why?\".\n- 'update': Update a queued item's message text. Name the item by\n  target_provider_id (a pending row's pid) OR, for a resolving row that has no\n  pid yet, by target_identifier (its URL/slug, shown on the row). Use this to\n  edit a queued message — including on resolving rows, which still hold the\n  message that will send once their profile resolves. When a target has more\n  than one queued action — a post with both a comment and a reaction, or a\n  person with a connection request and a follow — also pass action_type to name\n  which one to edit. A draft on a step running an A/B test carries `ab_version`\n  ('A', 'B', or 'left_out' when its send won't count) on its status row and in\n  this action's result; updating one takes ab_version too — the version the\n  edited draft reads as — or ab_version alone to re-file it unedited.\n- 'approve': Send authorization belongs to the user, so this action needs a\n  message that arrived after the drafts were queued and explicitly says to\n  approve or send them. A message from before the drafts existed cannot\n  authorize them — a request to review them, to approve them later, or to be\n  able to approve from chat means: report that the queue is awaiting approval\n  and end your turn; the user's next message decides. Once authorized, this\n  moves pending_approval items to 'pending'; they then send in queue order at\n  your account's pace. If\n  target_provider_id is given, approve only that item. Otherwise approve ALL\n  pending_approval items (optionally filtered by action_type).\n  Only touches items already awaiting approval — it does NOT run pending profile\n  lookups or pre-approve resolving rows (those aren't in the approvals UI, so\n  nobody has reviewed them; they resolve on their own schedule and, if the\n  user's settings gate the action, surface for approval once resolved).\n  From account-level chat an approve-all is rejected unless agent_id names the\n  campaign — it must not fire every campaign's drafts into sending at once.\n- 'cancel': Cancel a queued item. Pass target_provider_id to cancel that one\n  person or post — every queued action for them — or target_identifier to cancel\n  a resolving row that has no pid yet. To cancel the ENTIRE pending\n  queue — which drops drafts the user\n  already approved — you must pass\n  cancel_all=True; an unscoped cancel without it is rejected (an action_type\n  or node_id filter alone is still a bulk cancel and also needs cancel_all=True).\n  Narrow a cancel_all to one flow stage with node_id (e.g. restart only the m2\n  messages without touching m3) — the only way to separate two stages that share\n  an action_type. From account-level chat a cancel_all is rejected unless agent_id\n  names the campaign to cancel — it must not clear every campaign's queue at once.\n- 'pause': Pause the queue (stops sending, keeps items queued). Pass resume_at\n  to schedule an automatic resume (\"pause while I'm on vacation, resume July 20\");\n  without it the pause is indefinite and only an explicit 'resume' restarts sending.\n- 'resume': Resume the queue (pending items drain in queue order at your account's pace)"

Previous value: -[
-  {
-    "enum": [
-      "resolve",
-      "connection_request",
-      "message",
-      "inmail",
-      "follow",
-      "comment",
-      "reaction",
-      "withdrawal"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "resolve",
+      "connection_request",
+      "message",
+      "inmail",
+      "follow",
+      "comment",
+      "reaction",
+      "withdrawal"
+    ],
+    "title": "LinkedInQueueActionType",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Act on a consented teammate's queue instead of your own — pass\ntheir email. Covers approve / cancel / update / status; pause and resume\n(account-wide controls) are not available on a teammate's behalf. A bulk\napprove-all / cancel_all must name one of the teammate's campaigns via\nagent_id. Gated on that teammate's act-on-behalf setting; a teammate who\nhasn't granted it is rejected. Omit for your own."
-}

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Act on a consented teammate's queue instead of your own — pass\ntheir email. Covers approve / cancel / update / status; pause and resume\n(account-wide controls) are not available on a teammate's behalf. A bulk\napprove-all / cancel_all must name one of the teammate's campaigns via\nagent_id. Gated on that teammate's act-on-behalf setting; a teammate who\nhasn't granted it is rejected. Omit for your own.\nOr pass an agency client's email, from list_agency_clients, to run the call in that client's account, where none of the teammate limits above apply."
+}

Added value: +{
+  "anyOf": [
+    {
+      "description": "Which version of a step's A/B test a queued draft counts under, or LEFT_OUT of the test.",
+      "enum": [
+        "A",
+        "B",
+        "left_out"
+      ],
+      "title": "DraftVersion",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Required for 'update' of a draft in an A/B test — the version the edited\ndraft now reads as: 'A', 'B', or 'left_out' when it fits neither, so its send isn't\ncounted in the test; its current version when the edit doesn't change that. Omit\nfor a draft not in a test."
+}

Previous value: -"One of:\n- 'status': Get full queue details (pending/sent/failed items with names and times).\n  The `pending_items` / `pending_approval_items` / `failed_items` lists cap at 50\n  each, each with a matching `*_truncated` flag — when a list's flag is True, more\n  rows exist past this page; pass `offset` (offset += 50) to read them. Each\n  `failed_items` row carries `last_error`, the reason that send failed — read it to\n  answer \"why wasn't X sent?\". `pending_approval_items` rows also carry `last_error`\n  when the row was held for a reason beyond plain approval gating (e.g. the\n  resolver's name-mismatch hold). Queued post comments and reactions carry `post_url`\n  and a `post_text` excerpt of the post the action targets, so you can tell which\n  post a queued comment is on; `post_text_truncated` True means the target post ran\n  longer than the excerpt shown. All four lists share one field shape; a\n  `resolving_items` row (profile not yet resolved) has a blank `target_provider_id`\n  and its `message` is the copy that will send once it resolves — edit or cancel it\n  by its `target_identifier`. Every `pending_items` / `resolving_items` row carries\n  `projected_send_day` + `projected_send_time` (a resolving row's is its projected\n  lookup time, or its projected send time once it's a resolve-then-send) and a\n  `queue_position` — the row's place in the one ordered lookup+send timeline, so the\n  two lists interleave into what actually fires next. The top-level `cancelled_by_kind` maps each cancel\n  cause to its count (`recipient_replied`, `task_deleted`, `auto_shelved`, …;\n  pre-taxonomy rows under `unknown`) — read it to answer \"how much outreach was\n  cancelled, and why?\".\n- 'update': Update a queued item's message text. Name the item by\n  target_provider_id (a pending row's pid) OR, for a resolving row that has no\n  pid yet, by target_identifier (its URL/slug, shown on the row). Use this to\n  edit a queued message — including on resolving rows, which still hold the\n  message that will send once their profile resolves. When a target has more\n  than one queued action — a post with both a comment and a reaction, or a\n  person with a connection request and a follow — also pass action_type to name\n  which one to edit.\n- 'approve': Send authorization belongs to the user, so this action needs a\n  message that arrived after the drafts were queued and explicitly says to\n  approve or send them. A message from before the drafts existed cannot\n  authorize them — a request to review them, to approve them later, or to be\n  able to approve from chat means: report that the queue is awaiting approval\n  and end your turn; the user's next message decides. Once authorized, this\n  moves pending_approval items to 'pending'; they then send in queue order at\n  your account's pace. If\n  target_provider_id is given, approve only that item. Otherwise approve ALL\n  pending_approval items (optionally filtered by action_type).\n  Only touches items already awaiting approval — it does NOT run pending profile\n  lookups or pre-approve resolving rows (those aren't in the approvals UI, so\n  nobody has reviewed them; they resolve on their own schedule and, if the\n  user's settings gate the action, surface for approval once resolved).\n  From account-level chat an approve-all is rejected unless agent_id names the\n  campaign — it must not fire every campaign's drafts into sending at once.\n- 'cancel': Cancel a queued item. Pass target_provider_id to cancel that one\n  person or post — every queued action for them — or target_identifier to cancel\n  a resolving row that has no pid yet. To cancel the ENTIRE pending\n  queue — which drops drafts the user\n  already approved — you must pass\n  cancel_all=True; an unscoped cancel without it is rejected (an action_type\n  or node_id filter alone is still a bulk cancel and also needs cancel_all=True).\n  Narrow a cancel_all to one flow stage with node_id (e.g. restart only the m2\n  messages without touching m3) — the only way to separate two stages that share\n  an action_type. From account-level chat a cancel_all is rejected unless agent_id\n  names the campaign to cancel — it must not clear every campaign's queue at once.\n- 'pause': Pause the queue (stops sending, keeps items queued). Pass resume_at\n  to schedule an automatic resume (\"pause while I'm on vacation, resume July 20\");\n  without it the pause is indefinite and only an explicit 'resume' restarts sending.\n- 'resume': Resume the queue (pending items drain in queue order at your account's pace)"New value: +"One of:\n- 'status': Get full queue details (pending/sent/failed items with names and times).\n  The `pending_items` / `pending_approval_items` / `failed_items` lists cap at 50\n  each, each with a matching `*_truncated` flag — when a list's flag is True, more\n  rows exist past this page; pass `offset` (offset += 50) to read them. Each\n  `failed_items` row carries `last_error`, the reason that send failed — read it to\n  answer \"why wasn't X sent?\". `pending_approval_items` rows also carry `last_error`\n  when the row was held for a reason beyond plain approval gating (e.g. the\n  resolver's name-mismatch hold). Queued post comments and reactions carry `post_url`\n  and a `post_text` excerpt of the post the action targets, so you can tell which\n  post a queued comment is on; `post_text_truncated` True means the target post ran\n  longer than the excerpt shown. All four lists share one field shape; a\n  `resolving_items` row (profile not yet resolved) has a blank `target_provider_id`\n  and its `message` is the copy that will send once it resolves — edit or cancel it\n  by its `target_identifier`. Every `pending_items` / `resolving_items` row carries\n  `projected_send_day` + `projected_send_time` (a resolving row's is its projected\n  lookup time, or its projected send time once it's a resolve-then-send) and a\n  `queue_position` — the row's place in the one ordered lookup+send timeline, so the\n  two lists interleave into what actually fires next. The top-level `cancelled_by_kind` maps each cancel\n  cause to its count (`recipient_replied`, `task_deleted`, `auto_shelved`, …;\n  pre-taxonomy rows under `unknown`) — read it to answer \"how much outreach was\n  cancelled, and why?\".\n- 'update': Update a queued item's message text. Name the item by\n  target_provider_id (a pending row's pid) OR, for a resolving row that has no\n  pid yet, by target_identifier (its URL/slug, shown on the row). Use this to\n  edit a queued message — including on resolving rows, which still hold the\n  message that will send once their profile resolves. When a target has more\n  than one queued action — a post with both a comment and a reaction, or a\n  person with a connection request and a follow — also pass action_type to name\n  which one to edit. A draft on a step running an A/B test carries `ab_version`\n  ('A', 'B', or 'left_out' when its send won't count) on its status row and in\n  this action's result; updating one takes ab_version too — the version the\n  edited draft reads as — or ab_version alone to re-file it unedited.\n- 'approve': Send authorization belongs to the user, so this action needs a\n  message that arrived after the drafts were queued and explicitly says to\n  approve or send them. A message from before the drafts existed cannot\n  authorize them — a request to review them, to approve them later, or to be\n  able to approve from chat means: report that the queue is awaiting approval\n  and end your turn; the user's next message decides. Once authorized, this\n  moves pending_approval items to 'pending'; they then send in queue order at\n  your account's pace. If\n  target_provider_id is given, approve only that item. Otherwise approve ALL\n  pending_approval items (optionally filtered by action_type).\n  Only touches items already awaiting approval — it does NOT run pending profile\n  lookups or pre-approve resolving rows (those aren't in the approvals UI, so\n  nobody has reviewed them; they resolve on their own schedule and, if the\n  user's settings gate the action, surface for approval once resolved).\n  From account-level chat an approve-all is rejected unless agent_id names the\n  campaign — it must not fire every campaign's drafts into sending at once.\n- 'cancel': Cancel a queued item. Pass target_provider_id to cancel that one\n  person or post — every queued action for them — or target_identifier to cancel\n  a resolving row that has no pid yet. To cancel the ENTIRE pending\n  queue — which drops drafts the user\n  already approved — you must pass\n  cancel_all=True; an unscoped cancel without it is rejected (an action_type\n  or node_id filter alone is still a bulk cancel and also needs cancel_all=True).\n  Narrow a cancel_all to one flow stage with node_id (e.g. restart only the m2\n  messages without touching m3) — the only way to separate two stages that share\n  an action_type. From account-level chat a cancel_all is rejected unless agent_id\n  names the campaign to cancel — it must not clear every campaign's queue at once.\n- 'pause': Pause the queue (stops sending, keeps items queued). Pass resume_at\n  to schedule an automatic resume (\"pause while I'm on vacation, resume July 20\");\n  without it the pause is indefinite and only an explicit 'resume' restarts sending.\n- 'resume': Resume the queue (pending items drain in queue order at your account's pace)"

Previous value: -"One of:\n- 'status': Get full queue details (pending/sent/failed items with names and times).\n  The `pending_items` / `pending_approval_items` / `failed_items` lists cap at 50\n  each, each with a matching `*_truncated` flag — when a list's flag is True, more\n  rows exist past this page; pass `offset` (offset += 50) to read them. Each\n  `failed_items` row carries `last_error`, the reason that send failed — read it to\n  answer \"why wasn't X sent?\". `pending_approval_items` rows also carry `last_error`\n  when the row was held for a reason beyond plain approval gating (e.g. the\n  resolver's name-mismatch hold). Queued post comments and reactions carry `post_url`\n  and a `post_text` excerpt of the post the action targets, so you can tell which\n  post a queued comment is on; `post_text_truncated` True means the target post ran\n  longer than the excerpt shown. All four lists share one field shape; a\n  `resolving_items` row (profile not yet resolved) has a blank `target_provider_id`\n  and its `message` is the copy that will send once it resolves — edit or cancel it\n  by its `target_identifier`. Every `pending_items` / `resolving_items` row carries\n  `projected_send_day` + `projected_send_time` (a resolving row's is its projected\n  lookup time, or its projected send time once it's a resolve-then-send) and a\n  `queue_position` — the row's place in the one ordered lookup+send timeline, so the\n  two lists interleave into what actually fires next. The top-level `cancelled_by_kind` maps each cancel\n  cause to its count (`recipient_replied`, `task_deleted`, `auto_shelved`, …;\n  pre-taxonomy rows under `unknown`) — read it to answer \"how much outreach was\n  cancelled, and why?\".\n- 'update': Update a queued item's message text. Name the item by\n  target_provider_id (a pending row's pid) OR, for a resolving row that has no\n  pid yet, by target_identifier (its URL/slug, shown on the row). Use this to\n  edit a queued message — including on resolving rows, which still hold the\n  message that will send once their profile resolves. When a target has more\n  than one queued action — a post with both a comment and a reaction, or a\n  person with a connection request and a follow — also pass action_type to name\n  which one to edit.\n- 'approve': Send authorization belongs to the user, so this action needs a\n  message that arrived after the drafts were queued and explicitly says to\n  approve or send them. A message from before the drafts existed cannot\n  authorize them — a request to review them, to approve them later, or to be\n  able to approve from chat means: report that the queue is awaiting approval\n  and end your turn; the user's next message decides. Once authorized, this\n  moves pending_approval items to 'pending'; they then send in queue order at\n  your account's pace. If\n  target_provider_id is given, approve only that item. Otherwise approve ALL\n  pending_approval items (optionally filtered by action_type).\n  Only touches items already awaiting approval — it does NOT run pending profile\n  lookups or pre-approve resolving rows (those aren't in the approvals UI, so\n  nobody has reviewed them; they resolve on their own schedule and, if the\n  user's settings gate the action, surface for approval once resolved).\n  From account-level chat an approve-all is rejected unless task_id names the\n  campaign — it must not fire every campaign's drafts into sending at once.\n- 'cancel': Cancel a queued item. Pass target_provider_id to cancel that one\n  person or post — every queued action for them — or target_identifier to cancel\n  a resolving row that has no pid yet. To cancel the ENTIRE pending\n  queue — which drops drafts the user\n  already approved — you must pass\n  cancel_all=True; an unscoped cancel without it is rejected (an action_type\n  or node_id filter alone is still a bulk cancel and also needs cancel_all=True).\n  Narrow a cancel_all to one flow stage with node_id (e.g. restart only the m2\n  messages without touching m3) — the only way to separate two stages that share\n  an action_type. From account-level chat a cancel_all is rejected unless task_id\n  names the campaign to cancel — it must not clear every campaign's queue at once.\n- 'pause': Pause the queue (stops sending, keeps items queued). Pass resume_at\n  to schedule an automatic resume (\"pause while I'm on vacation, resume July 20\");\n  without it the pause is indefinite and only an explicit 'resume' restarts sending.\n- 'resume': Resume the queue (pending items drain in queue order at your account's pace)"New value: +"One of:\n- 'status': Get full queue details (pending/sent/failed items with names and times).\n  The `pending_items` / `pending_approval_items` / `failed_items` lists cap at 50\n  each, each with a matching `*_truncated` flag — when a list's flag is True, more\n  rows exist past this page; pass `offset` (offset += 50) to read them. Each\n  `failed_items` row carries `last_error`, the reason that send failed — read it to\n  answer \"why wasn't X sent?\". `pending_approval_items` rows also carry `last_error`\n  when the row was held for a reason beyond plain approval gating (e.g. the\n  resolver's name-mismatch hold). Queued post comments and reactions carry `post_url`\n  and a `post_text` excerpt of the post the action targets, so you can tell which\n  post a queued comment is on; `post_text_truncated` True means the target post ran\n  longer than the excerpt shown. All four lists share one field shape; a\n  `resolving_items` row (profile not yet resolved) has a blank `target_provider_id`\n  and its `message` is the copy that will send once it resolves — edit or cancel it\n  by its `target_identifier`. Every `pending_items` / `resolving_items` row carries\n  `projected_send_day` + `projected_send_time` (a resolving row's is its projected\n  lookup time, or its projected send time once it's a resolve-then-send) and a\n  `queue_position` — the row's place in the one ordered lookup+send timeline, so the\n  two lists interleave into what actually fires next. The top-level `cancelled_by_kind` maps each cancel\n  cause to its count (`recipient_replied`, `task_deleted`, `auto_shelved`, …;\n  pre-taxonomy rows under `unknown`) — read it to answer \"how much outreach was\n  cancelled, and why?\".\n- 'update': Update a queued item's message text. Name the item by\n  target_provider_id (a pending row's pid) OR, for a resolving row that has no\n  pid yet, by target_identifier (its URL/slug, shown on the row). Use this to\n  edit a queued message — including on resolving rows, which still hold the\n  message that will send once their profile resolves. When a target has more\n  than one queued action — a post with both a comment and a reaction, or a\n  person with a connection request and a follow — also pass action_type to name\n  which one to edit.\n- 'approve': Send authorization belongs to the user, so this action needs a\n  message that arrived after the drafts were queued and explicitly says to\n  approve or send them. A message from before the drafts existed cannot\n  authorize them — a request to review them, to approve them later, or to be\n  able to approve from chat means: report that the queue is awaiting approval\n  and end your turn; the user's next message decides. Once authorized, this\n  moves pending_approval items to 'pending'; they then send in queue order at\n  your account's pace. If\n  target_provider_id is given, approve only that item. Otherwise approve ALL\n  pending_approval items (optionally filtered by action_type).\n  Only touches items already awaiting approval — it does NOT run pending profile\n  lookups or pre-approve resolving rows (those aren't in the approvals UI, so\n  nobody has reviewed them; they resolve on their own schedule and, if the\n  user's settings gate the action, surface for approval once resolved).\n  From account-level chat an approve-all is rejected unless agent_id names the\n  campaign — it must not fire every campaign's drafts into sending at once.\n- 'cancel': Cancel a queued item. Pass target_provider_id to cancel that one\n  person or post — every queued action for them — or target_identifier to cancel\n  a resolving row that has no pid yet. To cancel the ENTIRE pending\n  queue — which drops drafts the user\n  already approved — you must pass\n  cancel_all=True; an unscoped cancel without it is rejected (an action_type\n  or node_id filter alone is still a bulk cancel and also needs cancel_all=True).\n  Narrow a cancel_all to one flow stage with node_id (e.g. restart only the m2\n  messages without touching m3) — the only way to separate two stages that share\n  an action_type. From account-level chat a cancel_all is rejected unless agent_id\n  names the campaign to cancel — it must not clear every campaign's queue at once.\n- 'pause': Pause the queue (stops sending, keeps items queued). Pass resume_at\n  to schedule an automatic resume (\"pause while I'm on vacation, resume July 20\");\n  without it the pause is indefinite and only an explicit 'resume' restarts sending.\n- 'resume': Resume the queue (pending items drain in queue order at your account's pace)"

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "For 'cancel' and 'approve' — scope a bulk cancel_all / approve-all to one\n    campaign's queue. Required from account-level chat (no active agent), where an\n    unscoped bulk cancel or approve is rejected; call list_agents to get the id."
+}

Previous value: -"Act on a consented teammate's queue instead of your own — pass\ntheir email. Covers approve / cancel / update / status; pause and resume\n(account-wide controls) are not available on a teammate's behalf. A bulk\napprove-all / cancel_all must name one of the teammate's campaigns via\ntask_id. Gated on that teammate's act-on-behalf setting; a teammate who\nhasn't granted it is rejected. Omit for your own."New value: +"Act on a consented teammate's queue instead of your own — pass\ntheir email. Covers approve / cancel / update / status; pause and resume\n(account-wide controls) are not available on a teammate's behalf. A bulk\napprove-all / cancel_all must name one of the teammate's campaigns via\nagent_id. Gated on that teammate's act-on-behalf setting; a teammate who\nhasn't granted it is rejected. Omit for your own."

Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "For 'cancel' and 'approve' — scope a bulk cancel_all / approve-all to one\n    campaign's queue. Required from account-level chat (no active task), where an\n    unscoped bulk cancel or approve is rejected; call list_agents to get the id."
-}

Previous value: -"For 'cancel' and 'approve' — scope a bulk cancel_all / approve-all to one\n    campaign's queue. Required from account-level chat (no active task), where an\n    unscoped bulk cancel or approve is rejected; call list_tasks to get the id."New value: +"For 'cancel' and 'approve' — scope a bulk cancel_all / approve-all to one\n    campaign's queue. Required from account-level chat (no active task), where an\n    unscoped bulk cancel or approve is rejected; call list_agents to get the id."