@zernio/node 0.2.988 → 0.2.990

package/dist/index.d.mts

@@ -1960,7 +1960,7 @@ type Ad = {
      */
     status?: (AdStatus);
     /**
-     * The ad's own on/off switch as configured on the platform, independent of its parents: an ACTIVE ad under a paused ad set or campaign still reads ACTIVE here while `status` reads `paused`. Sources: Meta `configured_status`, TikTok ad `operation_status` (ENABLE -> ACTIVE, DISABLE -> PAUSED), ChatGPT (OpenAI) ad `status` (ACTIVE / PAUSED, plus ARCHIVED on OpenAI). Distinct from `status`, which is the ancestor-cascaded delivery status. Only present for Meta, TikTok and OpenAI ads created or synced after the field was added for that platform; null otherwise.
+     * The ad's own on/off switch as configured on the platform, independent of its parents: an ACTIVE ad under a paused ad set or campaign still reads ACTIVE here while `status` reads `paused`. Sources: Meta `configured_status`, TikTok ad `operation_status` (ENABLE -> ACTIVE, DISABLE -> PAUSED), ChatGPT (OpenAI) ad `status` (ACTIVE / PAUSED, plus ARCHIVED on OpenAI). On create it is read back from the platform, not copied from the request, so it can read ACTIVE for a `PAUSED` create where the platform holds the pause at the campaign (some Meta create flows). A TikTok ad created `PAUSED` is switched off at the ad, ad group and campaign and reads PAUSED. Distinct from `status`, which is the ancestor-cascaded delivery status. Only present for Meta, TikTok and OpenAI ads created or synced after the field was added for that platform; null otherwise.
      */
     configuredStatus?: (string) | null;
     /**
@@ -38166,9 +38166,12 @@ type DuplicateAdCampaignData = {
          */
         statusOption?: 'ACTIVE' | 'PAUSED' | 'INHERITED_FROM_SOURCE';
         /**
-         * Reschedule the copied hierarchy's start time
+         * Reschedule the copied hierarchy's start (ISO 8601). On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone; LinkedIn ad accounts carry no timezone, so there it is read as UTC. TikTok defaults to a start a few minutes after the copy.
          */
         startTime?: string;
+        /**
+         * Reschedule the copied hierarchy's end, read like `startTime`; a date-only end runs to 23:59:59 local. Defaults to the source's end.
+         */
         endTime?: string;
         renameStrategy?: 'DEEP_RENAME' | 'ONLY_TOP_LEVEL_RENAME' | 'NO_RENAME';
         renamePrefix?: string;
@@ -38538,9 +38541,12 @@ type DuplicateAdSetData = {
         deepCopy?: boolean;
         statusOption?: 'ACTIVE' | 'PAUSED' | 'INHERITED_FROM_SOURCE';
         /**
-         * Reschedule the copy's start time
+         * Reschedule the copy's start (ISO 8601). A value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone.
          */
         startTime?: string;
+        /**
+         * Reschedule the copy's end, read like `startTime`; a date-only end runs to 23:59:59 local.
+         */
         endTime?: string;
         renameStrategy?: 'DEEP_RENAME' | 'ONLY_TOP_LEVEL_RENAME' | 'NO_RENAME';
         renamePrefix?: string;
@@ -42967,11 +42973,11 @@ type BoostPostData = {
          */
         currency?: string;
         /**
-         * Ad-set start time (ISO 8601, e.g. "2026-06-10T09:00:00Z"), mapped to the ad set's `start_time`. When omitted the ad starts delivering immediately. On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone. Same field as on POST /v1/ads/create.
+         * Ad-set start time (ISO 8601, e.g. "2026-06-10T09:00:00Z"), mapped to the ad set's `start_time`. When omitted the ad starts delivering immediately. On Meta, TikTok, X and Pinterest a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone. Same field as on POST /v1/ads/create.
          */
         startDate?: string;
         /**
-         * Ad-set end time (ISO 8601), mapped to the ad set's `end_time`. Required for lifetime budgets. On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone, and a date-only end runs to 23:59:59 local. Same field as on POST /v1/ads/create.
+         * Ad-set end time (ISO 8601), mapped to the ad set's `end_time`. Required for lifetime budgets. On Meta, TikTok, X and Pinterest a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone, and a date-only end runs to 23:59:59 local. Same field as on POST /v1/ads/create.
          */
         endDate?: string;
         /**
@@ -44110,16 +44116,18 @@ type CreateStandaloneAdData = {
             [key: string]: (number);
         };
         /**
-         * Required for lifetime budgets. On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone, and a date-only end runs to 23:59:59 local.
+         * Required for lifetime budgets. Read like `startDate` (account timezone on Meta, TikTok, X, Pinterest and OpenAI; whole account-local days on Google; UTC on LinkedIn), and a date-only end runs to 23:59:59 local.
          */
         endDate?: string;
         /**
          * Ad-set start time (ISO 8601, e.g. "2026-06-10T09:00:00Z"), mapped to the ad set's
          * start (Meta `start_time`, TikTok ad group `schedule_start_time`, LinkedIn / Pinterest / X
          * / Google campaign start). When omitted the ad starts delivering immediately. For lifetime
-         * budgets Meta also requires `endDate`. On Meta and TikTok a value without an offset
-         * (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account
-         * timezone (Meta itself would read it as UTC). The created ad's `schedule` echoes the start
+         * budgets Meta also requires `endDate`. On Meta, TikTok, X, Pinterest and OpenAI a value
+         * without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read
+         * in the ad account timezone (Meta itself would read it as UTC). Google runs whole days in
+         * the customer account timezone and takes the value's calendar date as written. LinkedIn
+         * ad accounts carry no timezone, so there a value without an offset is read as UTC. The created ad's `schedule` echoes the start
          * and end the platform stored, as UTC instants; when attaching to an existing ad set
          * (`adSetId`) it is that ad set's start and end. Same field as on `POST /v1/ads/boost`.
          *

package/dist/index.d.ts

@@ -1960,7 +1960,7 @@ type Ad = {
      */
     status?: (AdStatus);
     /**
-     * The ad's own on/off switch as configured on the platform, independent of its parents: an ACTIVE ad under a paused ad set or campaign still reads ACTIVE here while `status` reads `paused`. Sources: Meta `configured_status`, TikTok ad `operation_status` (ENABLE -> ACTIVE, DISABLE -> PAUSED), ChatGPT (OpenAI) ad `status` (ACTIVE / PAUSED, plus ARCHIVED on OpenAI). Distinct from `status`, which is the ancestor-cascaded delivery status. Only present for Meta, TikTok and OpenAI ads created or synced after the field was added for that platform; null otherwise.
+     * The ad's own on/off switch as configured on the platform, independent of its parents: an ACTIVE ad under a paused ad set or campaign still reads ACTIVE here while `status` reads `paused`. Sources: Meta `configured_status`, TikTok ad `operation_status` (ENABLE -> ACTIVE, DISABLE -> PAUSED), ChatGPT (OpenAI) ad `status` (ACTIVE / PAUSED, plus ARCHIVED on OpenAI). On create it is read back from the platform, not copied from the request, so it can read ACTIVE for a `PAUSED` create where the platform holds the pause at the campaign (some Meta create flows). A TikTok ad created `PAUSED` is switched off at the ad, ad group and campaign and reads PAUSED. Distinct from `status`, which is the ancestor-cascaded delivery status. Only present for Meta, TikTok and OpenAI ads created or synced after the field was added for that platform; null otherwise.
      */
     configuredStatus?: (string) | null;
     /**
@@ -38166,9 +38166,12 @@ type DuplicateAdCampaignData = {
          */
         statusOption?: 'ACTIVE' | 'PAUSED' | 'INHERITED_FROM_SOURCE';
         /**
-         * Reschedule the copied hierarchy's start time
+         * Reschedule the copied hierarchy's start (ISO 8601). On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone; LinkedIn ad accounts carry no timezone, so there it is read as UTC. TikTok defaults to a start a few minutes after the copy.
          */
         startTime?: string;
+        /**
+         * Reschedule the copied hierarchy's end, read like `startTime`; a date-only end runs to 23:59:59 local. Defaults to the source's end.
+         */
         endTime?: string;
         renameStrategy?: 'DEEP_RENAME' | 'ONLY_TOP_LEVEL_RENAME' | 'NO_RENAME';
         renamePrefix?: string;
@@ -38538,9 +38541,12 @@ type DuplicateAdSetData = {
         deepCopy?: boolean;
         statusOption?: 'ACTIVE' | 'PAUSED' | 'INHERITED_FROM_SOURCE';
         /**
-         * Reschedule the copy's start time
+         * Reschedule the copy's start (ISO 8601). A value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone.
          */
         startTime?: string;
+        /**
+         * Reschedule the copy's end, read like `startTime`; a date-only end runs to 23:59:59 local.
+         */
         endTime?: string;
         renameStrategy?: 'DEEP_RENAME' | 'ONLY_TOP_LEVEL_RENAME' | 'NO_RENAME';
         renamePrefix?: string;
@@ -42967,11 +42973,11 @@ type BoostPostData = {
          */
         currency?: string;
         /**
-         * Ad-set start time (ISO 8601, e.g. "2026-06-10T09:00:00Z"), mapped to the ad set's `start_time`. When omitted the ad starts delivering immediately. On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone. Same field as on POST /v1/ads/create.
+         * Ad-set start time (ISO 8601, e.g. "2026-06-10T09:00:00Z"), mapped to the ad set's `start_time`. When omitted the ad starts delivering immediately. On Meta, TikTok, X and Pinterest a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone. Same field as on POST /v1/ads/create.
          */
         startDate?: string;
         /**
-         * Ad-set end time (ISO 8601), mapped to the ad set's `end_time`. Required for lifetime budgets. On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone, and a date-only end runs to 23:59:59 local. Same field as on POST /v1/ads/create.
+         * Ad-set end time (ISO 8601), mapped to the ad set's `end_time`. Required for lifetime budgets. On Meta, TikTok, X and Pinterest a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone, and a date-only end runs to 23:59:59 local. Same field as on POST /v1/ads/create.
          */
         endDate?: string;
         /**
@@ -44110,16 +44116,18 @@ type CreateStandaloneAdData = {
             [key: string]: (number);
         };
         /**
-         * Required for lifetime budgets. On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone, and a date-only end runs to 23:59:59 local.
+         * Required for lifetime budgets. Read like `startDate` (account timezone on Meta, TikTok, X, Pinterest and OpenAI; whole account-local days on Google; UTC on LinkedIn), and a date-only end runs to 23:59:59 local.
          */
         endDate?: string;
         /**
          * Ad-set start time (ISO 8601, e.g. "2026-06-10T09:00:00Z"), mapped to the ad set's
          * start (Meta `start_time`, TikTok ad group `schedule_start_time`, LinkedIn / Pinterest / X
          * / Google campaign start). When omitted the ad starts delivering immediately. For lifetime
-         * budgets Meta also requires `endDate`. On Meta and TikTok a value without an offset
-         * (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account
-         * timezone (Meta itself would read it as UTC). The created ad's `schedule` echoes the start
+         * budgets Meta also requires `endDate`. On Meta, TikTok, X, Pinterest and OpenAI a value
+         * without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read
+         * in the ad account timezone (Meta itself would read it as UTC). Google runs whole days in
+         * the customer account timezone and takes the value's calendar date as written. LinkedIn
+         * ad accounts carry no timezone, so there a value without an offset is read as UTC. The created ad's `schedule` echoes the start
          * and end the platform stored, as UTC instants; when attaching to an existing ad set
          * (`adSetId`) it is that ad set's start and end. Same field as on `POST /v1/ads/boost`.
          *

package/dist/index.js

@@ -36,7 +36,7 @@ module.exports = __toCommonJS(index_exports);
 // package.json
 var package_default = {
   name: "@zernio/node",
-  version: "0.2.988",
+  version: "0.2.990",
   description: "The official Node.js library for the Zernio API",
   main: "dist/index.js",
   module: "dist/index.mjs",

package/dist/index.mjs

@@ -5,7 +5,7 @@ var __publicField = (obj, key, value) => __defNormalProp(obj, typeof key !== "sy
 // package.json
 var package_default = {
   name: "@zernio/node",
-  version: "0.2.988",
+  version: "0.2.990",
   description: "The official Node.js library for the Zernio API",
   main: "dist/index.js",
   module: "dist/index.mjs",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zernio/node",
-  "version": "0.2.988",
+  "version": "0.2.990",
   "description": "The official Node.js library for the Zernio API",
   "main": "dist/index.js",
   "module": "dist/index.mjs",

package/src/generated/sdk.gen.ts

@@ -10028,7 +10028,10 @@ export const deleteAd = <ThrowOnError extends boolean = false>(options: OptionsL
  * effective story/media IDs). `platform` is inferred from the ad, so it's
  * not required in the body. Ads in terminal statuses (rejected, completed,
  * cancelled) are skipped, and so is a request whose target already matches
- * the ad's own switch. The rolled-up `status` never decides a skip.
+ * the ad's own switch as read LIVE from the platform (a stored value is
+ * never trusted alone, since the switch may have been changed in the
+ * platform's own UI). A skip also returns that live read. The rolled-up
+ * `status` never decides a skip.
  *
  */
 export const updateAdStatus = <ThrowOnError extends boolean = false>(options: OptionsLegacyParser<UpdateAdStatusData, ThrowOnError>) => {

package/src/generated/types.gen.ts

@@ -92,7 +92,7 @@ export type Ad = {
      */
     status?: (AdStatus);
     /**
-     * The ad's own on/off switch as configured on the platform, independent of its parents: an ACTIVE ad under a paused ad set or campaign still reads ACTIVE here while `status` reads `paused`. Sources: Meta `configured_status`, TikTok ad `operation_status` (ENABLE -> ACTIVE, DISABLE -> PAUSED), ChatGPT (OpenAI) ad `status` (ACTIVE / PAUSED, plus ARCHIVED on OpenAI). Distinct from `status`, which is the ancestor-cascaded delivery status. Only present for Meta, TikTok and OpenAI ads created or synced after the field was added for that platform; null otherwise.
+     * The ad's own on/off switch as configured on the platform, independent of its parents: an ACTIVE ad under a paused ad set or campaign still reads ACTIVE here while `status` reads `paused`. Sources: Meta `configured_status`, TikTok ad `operation_status` (ENABLE -> ACTIVE, DISABLE -> PAUSED), ChatGPT (OpenAI) ad `status` (ACTIVE / PAUSED, plus ARCHIVED on OpenAI). On create it is read back from the platform, not copied from the request, so it can read ACTIVE for a `PAUSED` create where the platform holds the pause at the campaign (some Meta create flows). A TikTok ad created `PAUSED` is switched off at the ad, ad group and campaign and reads PAUSED. Distinct from `status`, which is the ancestor-cascaded delivery status. Only present for Meta, TikTok and OpenAI ads created or synced after the field was added for that platform; null otherwise.
      */
     configuredStatus?: (string) | null;
     /**
@@ -38556,9 +38556,12 @@ export type DuplicateAdCampaignData = {
          */
         statusOption?: 'ACTIVE' | 'PAUSED' | 'INHERITED_FROM_SOURCE';
         /**
-         * Reschedule the copied hierarchy's start time
+         * Reschedule the copied hierarchy's start (ISO 8601). On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone; LinkedIn ad accounts carry no timezone, so there it is read as UTC. TikTok defaults to a start a few minutes after the copy.
          */
         startTime?: string;
+        /**
+         * Reschedule the copied hierarchy's end, read like `startTime`; a date-only end runs to 23:59:59 local. Defaults to the source's end.
+         */
         endTime?: string;
         renameStrategy?: 'DEEP_RENAME' | 'ONLY_TOP_LEVEL_RENAME' | 'NO_RENAME';
         renamePrefix?: string;
@@ -38943,9 +38946,12 @@ export type DuplicateAdSetData = {
         deepCopy?: boolean;
         statusOption?: 'ACTIVE' | 'PAUSED' | 'INHERITED_FROM_SOURCE';
         /**
-         * Reschedule the copy's start time
+         * Reschedule the copy's start (ISO 8601). A value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone.
          */
         startTime?: string;
+        /**
+         * Reschedule the copy's end, read like `startTime`; a date-only end runs to 23:59:59 local.
+         */
         endTime?: string;
         renameStrategy?: 'DEEP_RENAME' | 'ONLY_TOP_LEVEL_RENAME' | 'NO_RENAME';
         renamePrefix?: string;
@@ -43684,11 +43690,11 @@ export type BoostPostData = {
          */
         currency?: string;
         /**
-         * Ad-set start time (ISO 8601, e.g. "2026-06-10T09:00:00Z"), mapped to the ad set's `start_time`. When omitted the ad starts delivering immediately. On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone. Same field as on POST /v1/ads/create.
+         * Ad-set start time (ISO 8601, e.g. "2026-06-10T09:00:00Z"), mapped to the ad set's `start_time`. When omitted the ad starts delivering immediately. On Meta, TikTok, X and Pinterest a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone. Same field as on POST /v1/ads/create.
          */
         startDate?: string;
         /**
-         * Ad-set end time (ISO 8601), mapped to the ad set's `end_time`. Required for lifetime budgets. On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone, and a date-only end runs to 23:59:59 local. Same field as on POST /v1/ads/create.
+         * Ad-set end time (ISO 8601), mapped to the ad set's `end_time`. Required for lifetime budgets. On Meta, TikTok, X and Pinterest a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone, and a date-only end runs to 23:59:59 local. Same field as on POST /v1/ads/create.
          */
         endDate?: string;
         /**
@@ -44851,16 +44857,18 @@ export type CreateStandaloneAdData = {
             [key: string]: (number);
         };
         /**
-         * Required for lifetime budgets. On Meta and TikTok a value without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account timezone, and a date-only end runs to 23:59:59 local.
+         * Required for lifetime budgets. Read like `startDate` (account timezone on Meta, TikTok, X, Pinterest and OpenAI; whole account-local days on Google; UTC on LinkedIn), and a date-only end runs to 23:59:59 local.
          */
         endDate?: string;
         /**
          * Ad-set start time (ISO 8601, e.g. "2026-06-10T09:00:00Z"), mapped to the ad set's
          * start (Meta `start_time`, TikTok ad group `schedule_start_time`, LinkedIn / Pinterest / X
          * / Google campaign start). When omitted the ad starts delivering immediately. For lifetime
-         * budgets Meta also requires `endDate`. On Meta and TikTok a value without an offset
-         * (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read in the ad account
-         * timezone (Meta itself would read it as UTC). The created ad's `schedule` echoes the start
+         * budgets Meta also requires `endDate`. On Meta, TikTok, X, Pinterest and OpenAI a value
+         * without an offset (`YYYY-MM-DD`, `YYYY-MM-DD HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS`) is read
+         * in the ad account timezone (Meta itself would read it as UTC). Google runs whole days in
+         * the customer account timezone and takes the value's calendar date as written. LinkedIn
+         * ad accounts carry no timezone, so there a value without an offset is read as UTC. The created ad's `schedule` echoes the start
          * and end the platform stored, as UTC instants; when attaching to an existing ad set
          * (`adSetId`) it is that ad set's start and end. Same field as on `POST /v1/ads/boost`.
          *