late-sdk 0.0.1180 → 0.0.1182

data/lib/zernio-sdk/api/ad_campaigns_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0
@@ -389,7 +389,7 @@ module Zernio
     end
 
     # Pause or resume many campaigns
-    # Process up to 50 campaigns in one call. Each campaign is updated concurrently and the response contains a per-campaign result so a single bad row does not fail the whole batch. 
+    # Process up to 50 campaigns in one call. Each campaign is updated concurrently and the response contains a per-campaign result so a single bad row does not fail the whole batch. Each campaign is written, counted and re-read exactly as PUT /v1/ads/campaigns/{campaignId}/status describes, including which child ad sets and ads each platform writes. 
     # @param bulk_update_ad_campaign_status_request [BulkUpdateAdCampaignStatusRequest] 
     # @param [Hash] opts the optional parameters
     # @return [BulkUpdateAdCampaignStatus200Response]
@@ -399,7 +399,7 @@ module Zernio
     end
 
     # Pause or resume many campaigns
-    # Process up to 50 campaigns in one call. Each campaign is updated concurrently and the response contains a per-campaign result so a single bad row does not fail the whole batch. 
+    # Process up to 50 campaigns in one call. Each campaign is updated concurrently and the response contains a per-campaign result so a single bad row does not fail the whole batch. Each campaign is written, counted and re-read exactly as PUT /v1/ads/campaigns/{campaignId}/status describes, including which child ad sets and ads each platform writes. 
     # @param bulk_update_ad_campaign_status_request [BulkUpdateAdCampaignStatusRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(BulkUpdateAdCampaignStatus200Response, Integer, Hash)>] BulkUpdateAdCampaignStatus200Response data, response status code and response headers
@@ -1426,9 +1426,10 @@ module Zernio
     end
 
     # Get ad details
-    # Returns an ad with its creative, targeting, status, and performance metrics. Google Search ads include current creative.headlines, creative.descriptions and creative.finalUrls, preserving pinnedField. Top-level cachedAt and stale report cache freshness. Google mutations invalidate this read. RSA enrichment requires a stored advertisingChannelType of SEARCH. Ads with an unknown or other channel return their stored details without a Google read. If RSA enrichment fails, the stored ad is returned with HTTP 200 and without cache metadata.  The `{adId}` path segment accepts any identifier dialect Zernio indexes for the ad: - the Zernio internal `_id` (24-char hex) - Meta's numeric `platformAdId` (the value shipped in `comment.received` webhooks as `comment.ad.id`) - the creative's `effective_object_story_id` (`{pageId}_{postId}` shape, Facebook side) - the creative's `effective_instagram_media_id` (Instagram side)  Any of the four resolve to the same ad. Caller doesn't need a translation step. `creative.creativeFeatures` holds the stored requested settings, which do not confirm platform application. 
+    # Returns an ad with its creative, targeting, status, and performance metrics. Google Search ads include current creative.headlines, creative.descriptions and creative.finalUrls, preserving pinnedField. Top-level cachedAt and stale report cache freshness. Google mutations invalidate this read. RSA enrichment requires a stored advertisingChannelType of SEARCH. Ads with an unknown or other channel return their stored details without a Google read. If RSA enrichment fails, the stored ad is returned with HTTP 200 and without cache metadata.  The `{adId}` path segment accepts any identifier dialect Zernio indexes for the ad: - the Zernio internal `_id` (24-char hex) - Meta's numeric `platformAdId` (the value shipped in `comment.received` webhooks as `comment.ad.id`) - the creative's `effective_object_story_id` (`{pageId}_{postId}` shape, Facebook side) - the creative's `effective_instagram_media_id` (Instagram side)  Any of the four resolve to the same ad. Caller doesn't need a translation step. `creative.creativeFeatures` holds the stored requested settings, which do not confirm platform application.  **Status freshness.** `status`, `configuredStatus`, `platformStatus`, `platformAdSetStatus` and `platformCampaignStatus` are the values Zernio last stored. Background sync refreshes them, typically within 15 to 60 minutes (Google up to about 3 hours), and ended or long-paused objects may be refreshed less often. Zernio's own status writes re-read the switches they change. A change made in the platform's own ads manager therefore shows up here only after the next sync. Controllers that act on a switch should pass `live=true`, which reads the switches from the platform now, stores them, and returns `statusReadAt` (null when the read failed and the stored values were returned). With `live=true` the ad's own switch (`configuredStatus`), its delivery status (`status`, `platformStatus`) and its ad set and campaign switches (`platformAdSetStatus`, `platformCampaignStatus`) are read live. 
     # @param ad_id [String] Zernio &#x60;_id&#x60; (hex), Meta &#x60;platformAdId&#x60; (numeric), or one of the creative&#39;s effective story/media IDs. See description for details. 
     # @param [Hash] opts the optional parameters
+    # @option opts [Boolean] :live Read the on/off switches live from the platform instead of returning the synced values. The fresh values are stored (so later reads return them too) and the response carries &#x60;statusReadAt&#x60;, the time of the read. At most 20 platform objects are read per request. Where a read fails (credentials, platform error, no reader on that platform), the stored values come back with &#x60;statusReadAt: null&#x60;. See \&quot;Status freshness\&quot; in the operation description. (default to false)
     # @return [GetAd200Response]
     def get_ad(ad_id, opts = {})
       data, _status_code, _headers = get_ad_with_http_info(ad_id, opts)
@@ -1436,9 +1437,10 @@ module Zernio
     end
 
     # Get ad details
-    # Returns an ad with its creative, targeting, status, and performance metrics. Google Search ads include current creative.headlines, creative.descriptions and creative.finalUrls, preserving pinnedField. Top-level cachedAt and stale report cache freshness. Google mutations invalidate this read. RSA enrichment requires a stored advertisingChannelType of SEARCH. Ads with an unknown or other channel return their stored details without a Google read. If RSA enrichment fails, the stored ad is returned with HTTP 200 and without cache metadata.  The &#x60;{adId}&#x60; path segment accepts any identifier dialect Zernio indexes for the ad: - the Zernio internal &#x60;_id&#x60; (24-char hex) - Meta&#39;s numeric &#x60;platformAdId&#x60; (the value shipped in &#x60;comment.received&#x60; webhooks as &#x60;comment.ad.id&#x60;) - the creative&#39;s &#x60;effective_object_story_id&#x60; (&#x60;{pageId}_{postId}&#x60; shape, Facebook side) - the creative&#39;s &#x60;effective_instagram_media_id&#x60; (Instagram side)  Any of the four resolve to the same ad. Caller doesn&#39;t need a translation step. &#x60;creative.creativeFeatures&#x60; holds the stored requested settings, which do not confirm platform application. 
+    # Returns an ad with its creative, targeting, status, and performance metrics. Google Search ads include current creative.headlines, creative.descriptions and creative.finalUrls, preserving pinnedField. Top-level cachedAt and stale report cache freshness. Google mutations invalidate this read. RSA enrichment requires a stored advertisingChannelType of SEARCH. Ads with an unknown or other channel return their stored details without a Google read. If RSA enrichment fails, the stored ad is returned with HTTP 200 and without cache metadata.  The &#x60;{adId}&#x60; path segment accepts any identifier dialect Zernio indexes for the ad: - the Zernio internal &#x60;_id&#x60; (24-char hex) - Meta&#39;s numeric &#x60;platformAdId&#x60; (the value shipped in &#x60;comment.received&#x60; webhooks as &#x60;comment.ad.id&#x60;) - the creative&#39;s &#x60;effective_object_story_id&#x60; (&#x60;{pageId}_{postId}&#x60; shape, Facebook side) - the creative&#39;s &#x60;effective_instagram_media_id&#x60; (Instagram side)  Any of the four resolve to the same ad. Caller doesn&#39;t need a translation step. &#x60;creative.creativeFeatures&#x60; holds the stored requested settings, which do not confirm platform application.  **Status freshness.** &#x60;status&#x60;, &#x60;configuredStatus&#x60;, &#x60;platformStatus&#x60;, &#x60;platformAdSetStatus&#x60; and &#x60;platformCampaignStatus&#x60; are the values Zernio last stored. Background sync refreshes them, typically within 15 to 60 minutes (Google up to about 3 hours), and ended or long-paused objects may be refreshed less often. Zernio&#39;s own status writes re-read the switches they change. A change made in the platform&#39;s own ads manager therefore shows up here only after the next sync. Controllers that act on a switch should pass &#x60;live&#x3D;true&#x60;, which reads the switches from the platform now, stores them, and returns &#x60;statusReadAt&#x60; (null when the read failed and the stored values were returned). With &#x60;live&#x3D;true&#x60; the ad&#39;s own switch (&#x60;configuredStatus&#x60;), its delivery status (&#x60;status&#x60;, &#x60;platformStatus&#x60;) and its ad set and campaign switches (&#x60;platformAdSetStatus&#x60;, &#x60;platformCampaignStatus&#x60;) are read live. 
     # @param ad_id [String] Zernio &#x60;_id&#x60; (hex), Meta &#x60;platformAdId&#x60; (numeric), or one of the creative&#39;s effective story/media IDs. See description for details. 
     # @param [Hash] opts the optional parameters
+    # @option opts [Boolean] :live Read the on/off switches live from the platform instead of returning the synced values. The fresh values are stored (so later reads return them too) and the response carries &#x60;statusReadAt&#x60;, the time of the read. At most 20 platform objects are read per request. Where a read fails (credentials, platform error, no reader on that platform), the stored values come back with &#x60;statusReadAt: null&#x60;. See \&quot;Status freshness\&quot; in the operation description. (default to false)
     # @return [Array<(GetAd200Response, Integer, Hash)>] GetAd200Response data, response status code and response headers
     def get_ad_with_http_info(ad_id, opts = {})
       if @api_client.config.debugging
@@ -1453,6 +1455,7 @@ module Zernio
 
       # query parameters
       query_params = opts[:query_params] || {}
+      query_params[:'live'] = opts[:'live'] if !opts[:'live'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}
@@ -2261,7 +2264,7 @@ module Zernio
     end
 
     # List campaigns
-    # Returns campaigns as virtual aggregations over ad documents grouped by platform campaign ID. Metrics (spend, impressions, clicks, etc.) are summed across all ads in each campaign. Campaign status is derived from child ad statuses (active > pending_review > paused > error > completed > cancelled > rejected). Google campaign budgets include amountMicros, explicitlyShared, resourceName and deliveryMethod after the next successful sync. This endpoint does not fetch Google live. 
+    # Returns campaigns as virtual aggregations over ad documents grouped by platform campaign ID. Metrics (spend, impressions, clicks, etc.) are summed across all ads in each campaign. Campaign status is derived from child ad statuses (active > pending_review > paused > error > completed > cancelled > rejected). Google campaign budgets include amountMicros, explicitlyShared, resourceName and deliveryMethod after the next successful sync. This endpoint does not fetch Google live.  **Status freshness.** `status`, `configuredStatus`, `platformStatus`, `platformAdSetStatus` and `platformCampaignStatus` are the values Zernio last stored. Background sync refreshes them, typically within 15 to 60 minutes (Google up to about 3 hours), and ended or long-paused objects may be refreshed less often. Zernio's own status writes re-read the switches they change. A change made in the platform's own ads manager therefore shows up here only after the next sync. Controllers that act on a switch should pass `live=true`, which reads the switches from the platform now, stores them, and returns `statusReadAt` (null when the read failed and the stored values were returned). With `live=true` (which needs `limit` of 20 or less) each returned campaign's own switch (`platformCampaignStatus`) is read live. Live reads cover TikTok, Meta, Google and OpenAI. The rolled-up `status` is not re-derived by a live read. 
     # @param [Hash] opts the optional parameters
     # @option opts [Boolean] :include_empty Meta only. Campaign reads aggregate over ad documents, so a campaign with ZERO ads is normally invisible here, the state the two-step create (campaign, then ads via &#x60;existingCampaignId&#x60;) leaves behind whenever Meta rejects the ad step. Set true to list those too, with &#x60;adCount: 0&#x60; and zeroed metrics. Requires &#x60;accountId&#x60; and &#x60;adAccountId&#x60;, since an empty campaign has no ad row to resolve a token or ad account from.
     # @option opts [Integer] :page Page number (1-based) (default to 1)
@@ -2277,6 +2280,7 @@ module Zernio
     # @option opts [Date] :to_date End of metrics date range (YYYY-MM-DD, inclusive). Defaults to today. Max 730-day range.
     # @option opts [Boolean] :has_delivery Return only campaigns that delivered between &#x60;fromDate&#x60; and &#x60;toDate&#x60;: spend above zero, or impressions served at zero spend. Unlike &#x60;status&#x60;, which reads a campaign&#39;s CURRENT state, this filters on what happened inside the window. Filters the campaign set itself, so &#x60;pagination.total&#x60; counts only matching campaigns. Mirrors the same filter on /v1/ads/tree.
     # @option opts [Float] :min_spend Return only campaigns whose spend between &#x60;fromDate&#x60; and &#x60;toDate&#x60; reaches this amount, in each campaign&#39;s OWN currency (the &#x60;currency&#x60; field on the campaign). Implies &#x60;hasDelivery&#x60;; &#x60;minSpend&#x3D;0&#x60; applies no filter. Mirrors the same filter on /v1/ads/tree.
+    # @option opts [Boolean] :live Read the on/off switches live from the platform instead of returning the synced values. The fresh values are stored (so later reads return them too) and the response carries &#x60;statusReadAt&#x60;, the time of the read. At most 20 platform objects are read per request. Where a read fails (credentials, platform error, no reader on that platform), the stored values come back with &#x60;statusReadAt: null&#x60;. See \&quot;Status freshness\&quot; in the operation description. (default to false)
     # @return [ListAdCampaigns200Response]
     def list_ad_campaigns(opts = {})
       data, _status_code, _headers = list_ad_campaigns_with_http_info(opts)
@@ -2284,7 +2288,7 @@ module Zernio
     end
 
     # List campaigns
-    # Returns campaigns as virtual aggregations over ad documents grouped by platform campaign ID. Metrics (spend, impressions, clicks, etc.) are summed across all ads in each campaign. Campaign status is derived from child ad statuses (active &gt; pending_review &gt; paused &gt; error &gt; completed &gt; cancelled &gt; rejected). Google campaign budgets include amountMicros, explicitlyShared, resourceName and deliveryMethod after the next successful sync. This endpoint does not fetch Google live. 
+    # Returns campaigns as virtual aggregations over ad documents grouped by platform campaign ID. Metrics (spend, impressions, clicks, etc.) are summed across all ads in each campaign. Campaign status is derived from child ad statuses (active &gt; pending_review &gt; paused &gt; error &gt; completed &gt; cancelled &gt; rejected). Google campaign budgets include amountMicros, explicitlyShared, resourceName and deliveryMethod after the next successful sync. This endpoint does not fetch Google live.  **Status freshness.** &#x60;status&#x60;, &#x60;configuredStatus&#x60;, &#x60;platformStatus&#x60;, &#x60;platformAdSetStatus&#x60; and &#x60;platformCampaignStatus&#x60; are the values Zernio last stored. Background sync refreshes them, typically within 15 to 60 minutes (Google up to about 3 hours), and ended or long-paused objects may be refreshed less often. Zernio&#39;s own status writes re-read the switches they change. A change made in the platform&#39;s own ads manager therefore shows up here only after the next sync. Controllers that act on a switch should pass &#x60;live&#x3D;true&#x60;, which reads the switches from the platform now, stores them, and returns &#x60;statusReadAt&#x60; (null when the read failed and the stored values were returned). With &#x60;live&#x3D;true&#x60; (which needs &#x60;limit&#x60; of 20 or less) each returned campaign&#39;s own switch (&#x60;platformCampaignStatus&#x60;) is read live. Live reads cover TikTok, Meta, Google and OpenAI. The rolled-up &#x60;status&#x60; is not re-derived by a live read. 
     # @param [Hash] opts the optional parameters
     # @option opts [Boolean] :include_empty Meta only. Campaign reads aggregate over ad documents, so a campaign with ZERO ads is normally invisible here, the state the two-step create (campaign, then ads via &#x60;existingCampaignId&#x60;) leaves behind whenever Meta rejects the ad step. Set true to list those too, with &#x60;adCount: 0&#x60; and zeroed metrics. Requires &#x60;accountId&#x60; and &#x60;adAccountId&#x60;, since an empty campaign has no ad row to resolve a token or ad account from.
     # @option opts [Integer] :page Page number (1-based) (default to 1)
@@ -2300,6 +2304,7 @@ module Zernio
     # @option opts [Date] :to_date End of metrics date range (YYYY-MM-DD, inclusive). Defaults to today. Max 730-day range.
     # @option opts [Boolean] :has_delivery Return only campaigns that delivered between &#x60;fromDate&#x60; and &#x60;toDate&#x60;: spend above zero, or impressions served at zero spend. Unlike &#x60;status&#x60;, which reads a campaign&#39;s CURRENT state, this filters on what happened inside the window. Filters the campaign set itself, so &#x60;pagination.total&#x60; counts only matching campaigns. Mirrors the same filter on /v1/ads/tree.
     # @option opts [Float] :min_spend Return only campaigns whose spend between &#x60;fromDate&#x60; and &#x60;toDate&#x60; reaches this amount, in each campaign&#39;s OWN currency (the &#x60;currency&#x60; field on the campaign). Implies &#x60;hasDelivery&#x60;; &#x60;minSpend&#x3D;0&#x60; applies no filter. Mirrors the same filter on /v1/ads/tree.
+    # @option opts [Boolean] :live Read the on/off switches live from the platform instead of returning the synced values. The fresh values are stored (so later reads return them too) and the response carries &#x60;statusReadAt&#x60;, the time of the read. At most 20 platform objects are read per request. Where a read fails (credentials, platform error, no reader on that platform), the stored values come back with &#x60;statusReadAt: null&#x60;. See \&quot;Status freshness\&quot; in the operation description. (default to false)
     # @return [Array<(ListAdCampaigns200Response, Integer, Hash)>] ListAdCampaigns200Response data, response status code and response headers
     def list_ad_campaigns_with_http_info(opts = {})
       if @api_client.config.debugging
@@ -2348,6 +2353,7 @@ module Zernio
       query_params[:'toDate'] = opts[:'to_date'] if !opts[:'to_date'].nil?
       query_params[:'hasDelivery'] = opts[:'has_delivery'] if !opts[:'has_delivery'].nil?
       query_params[:'minSpend'] = opts[:'min_spend'] if !opts[:'min_spend'].nil?
+      query_params[:'live'] = opts[:'live'] if !opts[:'live'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}
@@ -2594,11 +2600,13 @@ module Zernio
     end
 
     # List ad sets
-    # Ad sets (Google ad groups) synced for the connection, optionally filtered by platform and campaignId. Reads the `ad_sets` table directly, independent of the `ads` rollup GET /v1/ads/tree uses, so a newly created standalone ad group with no ad yet (POST /v1/ads/ad-sets, Google only) is visible here even though it is invisible in the tree until an ad joins it via `adSetId` on POST /v1/ads/create. Returns at most 500 rows, newest first.
+    # Ad sets (Google ad groups) synced for the connection, optionally filtered by platform and campaignId. Reads the `ad_sets` table directly, independent of the `ads` rollup GET /v1/ads/tree uses, so a newly created standalone ad group with no ad yet (POST /v1/ads/ad-sets, Google only) is visible here even though it is invisible in the tree until an ad joins it via `adSetId` on POST /v1/ads/create. Returns at most 500 rows, newest first.  **Status freshness.** `status`, `configuredStatus`, `platformStatus`, `platformAdSetStatus` and `platformCampaignStatus` are the values Zernio last stored. Background sync refreshes them, typically within 15 to 60 minutes (Google up to about 3 hours), and ended or long-paused objects may be refreshed less often. Zernio's own status writes re-read the switches they change. A change made in the platform's own ads manager therefore shows up here only after the next sync. Controllers that act on a switch should pass `live=true`, which reads the switches from the platform now, stores them, and returns `statusReadAt` (null when the read failed and the stored values were returned). With `live=true` (which needs a `campaignId` or `adSetId` filter) each listed ad set's own switch (`platformAdSetStatus`) is read live, for the first 20 rows; later rows keep their synced value with `statusReadAt: null`. Live reads cover TikTok, Meta, Google and OpenAI. The rolled-up `status` is not re-derived by a live read.
     # @param [Hash] opts the optional parameters
     # @option opts [String] :account_id Account ID
     # @option opts [String] :campaign_id Platform campaign ID
+    # @option opts [String] :ad_set_id Platform ad set ID
     # @option opts [String] :platform 
+    # @option opts [Boolean] :live Read the on/off switches live from the platform instead of returning the synced values. The fresh values are stored (so later reads return them too) and the response carries &#x60;statusReadAt&#x60;, the time of the read. At most 20 platform objects are read per request. Where a read fails (credentials, platform error, no reader on that platform), the stored values come back with &#x60;statusReadAt: null&#x60;. See \&quot;Status freshness\&quot; in the operation description. (default to false)
     # @return [ListAdSets200Response]
     def list_ad_sets(opts = {})
       data, _status_code, _headers = list_ad_sets_with_http_info(opts)
@@ -2606,11 +2614,13 @@ module Zernio
     end
 
     # List ad sets
-    # Ad sets (Google ad groups) synced for the connection, optionally filtered by platform and campaignId. Reads the &#x60;ad_sets&#x60; table directly, independent of the &#x60;ads&#x60; rollup GET /v1/ads/tree uses, so a newly created standalone ad group with no ad yet (POST /v1/ads/ad-sets, Google only) is visible here even though it is invisible in the tree until an ad joins it via &#x60;adSetId&#x60; on POST /v1/ads/create. Returns at most 500 rows, newest first.
+    # Ad sets (Google ad groups) synced for the connection, optionally filtered by platform and campaignId. Reads the &#x60;ad_sets&#x60; table directly, independent of the &#x60;ads&#x60; rollup GET /v1/ads/tree uses, so a newly created standalone ad group with no ad yet (POST /v1/ads/ad-sets, Google only) is visible here even though it is invisible in the tree until an ad joins it via &#x60;adSetId&#x60; on POST /v1/ads/create. Returns at most 500 rows, newest first.  **Status freshness.** &#x60;status&#x60;, &#x60;configuredStatus&#x60;, &#x60;platformStatus&#x60;, &#x60;platformAdSetStatus&#x60; and &#x60;platformCampaignStatus&#x60; are the values Zernio last stored. Background sync refreshes them, typically within 15 to 60 minutes (Google up to about 3 hours), and ended or long-paused objects may be refreshed less often. Zernio&#39;s own status writes re-read the switches they change. A change made in the platform&#39;s own ads manager therefore shows up here only after the next sync. Controllers that act on a switch should pass &#x60;live&#x3D;true&#x60;, which reads the switches from the platform now, stores them, and returns &#x60;statusReadAt&#x60; (null when the read failed and the stored values were returned). With &#x60;live&#x3D;true&#x60; (which needs a &#x60;campaignId&#x60; or &#x60;adSetId&#x60; filter) each listed ad set&#39;s own switch (&#x60;platformAdSetStatus&#x60;) is read live, for the first 20 rows; later rows keep their synced value with &#x60;statusReadAt: null&#x60;. Live reads cover TikTok, Meta, Google and OpenAI. The rolled-up &#x60;status&#x60; is not re-derived by a live read.
     # @param [Hash] opts the optional parameters
     # @option opts [String] :account_id Account ID
     # @option opts [String] :campaign_id Platform campaign ID
+    # @option opts [String] :ad_set_id Platform ad set ID
     # @option opts [String] :platform 
+    # @option opts [Boolean] :live Read the on/off switches live from the platform instead of returning the synced values. The fresh values are stored (so later reads return them too) and the response carries &#x60;statusReadAt&#x60;, the time of the read. At most 20 platform objects are read per request. Where a read fails (credentials, platform error, no reader on that platform), the stored values come back with &#x60;statusReadAt: null&#x60;. See \&quot;Status freshness\&quot; in the operation description. (default to false)
     # @return [Array<(ListAdSets200Response, Integer, Hash)>] ListAdSets200Response data, response status code and response headers
     def list_ad_sets_with_http_info(opts = {})
       if @api_client.config.debugging
@@ -2627,7 +2637,9 @@ module Zernio
       query_params = opts[:query_params] || {}
       query_params[:'accountId'] = opts[:'account_id'] if !opts[:'account_id'].nil?
       query_params[:'campaignId'] = opts[:'campaign_id'] if !opts[:'campaign_id'].nil?
+      query_params[:'adSetId'] = opts[:'ad_set_id'] if !opts[:'ad_set_id'].nil?
       query_params[:'platform'] = opts[:'platform'] if !opts[:'platform'].nil?
+      query_params[:'live'] = opts[:'live'] if !opts[:'live'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}
@@ -3949,7 +3961,7 @@ module Zernio
     end
 
     # Pause or resume a campaign
-    # Writes the campaign's own on/off switch, then lets the platform cascade delivery to its ad sets and ads. Makes one platform API call, not one per ad.  The switch is always written, whatever delivery status the ads underneath report: an ad still in review does not block resuming its campaign. The echoed `status` is the confirmation that it landed.  `updated` / `skipped` describe only the ads whose own stored status CHANGED alongside it, so `updated: 0` is a normal successful response, not a no-op. Ads are skipped when they are in a terminal status (rejected, completed, cancelled), already in the target state, or switched on but not yet delivering. The last group keeps its `pending_review` / `error` status until the platform reports what it became. `skippedReasons` names which case applies.  On Meta this flips the campaign only. An ad set paused in its own right stays paused, so pair this with PUT /v1/ads/ad-sets/{adSetId}/status when you also need the ad set switched back on.  Google keeps an independent on/off switch at campaign, ad group and ad level and the most restrictive one wins, so `active` switches the campaign on TOGETHER with the ad groups and ads Zernio tracks under it, in one mutate. Without that the campaign reads ENABLED while a paused ad group or ad keeps it from serving. `paused` writes the campaign alone, which already stops delivery and leaves each ad's own switch as you set it. 
+    # Writes the campaign's own on/off switch, then lets the platform cascade delivery to its ad sets and ads.  **What the write touches (current semantics, per platform).** TikTok: the campaign, every ad group and every ad under it that is not in a terminal status (rejected, completed, cancelled), on pause and on resume alike, so a resume also switches those ad groups and ads on. LinkedIn: the campaign group plus the campaigns and creatives of its non-terminal ads. Google: `paused` writes the campaign alone; `active` also switches on the ad groups and ads Zernio tracks under it (see below). Pinterest: the campaign plus one tracked ad and its ad group. X: the campaign plus one tracked line item. Meta and ChatGPT (OpenAI): the campaign switch only.  **Counts and readback.** Before the write, each ad's own switch is read live from the platform (up to 20 ads; beyond that the stored switch is used), and `updated` / `skipped` are computed against that live state. After the write each ad's own switch and delivery status are read again and stored, and the campaign switch is re-read and stored, so an immediate GET returns what the platform now reports.  The switch is always written, whatever delivery status the ads underneath report: an ad still in review does not block resuming its campaign. The echoed `status` is the confirmation that it landed.  `updated` / `skipped` describe only the ads whose own status changed alongside it, so `updated: 0` is a normal successful response, not a no-op. Ads are skipped when they are in a terminal status (rejected, completed, cancelled), already in the target state, or switched on but not yet delivering. The last group keeps its `pending_review` / `error` status until the platform reports what it became. `skippedReasons` names which case applies.  On Meta this flips the campaign only. An ad set paused in its own right stays paused, so pair this with PUT /v1/ads/ad-sets/{adSetId}/status when you also need the ad set switched back on.  Google keeps an independent on/off switch at campaign, ad group and ad level and the most restrictive one wins, so `active` switches the campaign on TOGETHER with the ad groups and ads Zernio tracks under it, in one mutate. Without that the campaign reads ENABLED while a paused ad group or ad keeps it from serving. `paused` writes the campaign alone, which already stops delivery and leaves each ad's own switch as you set it. 
     # @param campaign_id [String] Platform campaign ID
     # @param update_ad_campaign_status_request [UpdateAdCampaignStatusRequest] 
     # @param [Hash] opts the optional parameters
@@ -3960,7 +3972,7 @@ module Zernio
     end
 
     # Pause or resume a campaign
-    # Writes the campaign&#39;s own on/off switch, then lets the platform cascade delivery to its ad sets and ads. Makes one platform API call, not one per ad.  The switch is always written, whatever delivery status the ads underneath report: an ad still in review does not block resuming its campaign. The echoed &#x60;status&#x60; is the confirmation that it landed.  &#x60;updated&#x60; / &#x60;skipped&#x60; describe only the ads whose own stored status CHANGED alongside it, so &#x60;updated: 0&#x60; is a normal successful response, not a no-op. Ads are skipped when they are in a terminal status (rejected, completed, cancelled), already in the target state, or switched on but not yet delivering. The last group keeps its &#x60;pending_review&#x60; / &#x60;error&#x60; status until the platform reports what it became. &#x60;skippedReasons&#x60; names which case applies.  On Meta this flips the campaign only. An ad set paused in its own right stays paused, so pair this with PUT /v1/ads/ad-sets/{adSetId}/status when you also need the ad set switched back on.  Google keeps an independent on/off switch at campaign, ad group and ad level and the most restrictive one wins, so &#x60;active&#x60; switches the campaign on TOGETHER with the ad groups and ads Zernio tracks under it, in one mutate. Without that the campaign reads ENABLED while a paused ad group or ad keeps it from serving. &#x60;paused&#x60; writes the campaign alone, which already stops delivery and leaves each ad&#39;s own switch as you set it. 
+    # Writes the campaign&#39;s own on/off switch, then lets the platform cascade delivery to its ad sets and ads.  **What the write touches (current semantics, per platform).** TikTok: the campaign, every ad group and every ad under it that is not in a terminal status (rejected, completed, cancelled), on pause and on resume alike, so a resume also switches those ad groups and ads on. LinkedIn: the campaign group plus the campaigns and creatives of its non-terminal ads. Google: &#x60;paused&#x60; writes the campaign alone; &#x60;active&#x60; also switches on the ad groups and ads Zernio tracks under it (see below). Pinterest: the campaign plus one tracked ad and its ad group. X: the campaign plus one tracked line item. Meta and ChatGPT (OpenAI): the campaign switch only.  **Counts and readback.** Before the write, each ad&#39;s own switch is read live from the platform (up to 20 ads; beyond that the stored switch is used), and &#x60;updated&#x60; / &#x60;skipped&#x60; are computed against that live state. After the write each ad&#39;s own switch and delivery status are read again and stored, and the campaign switch is re-read and stored, so an immediate GET returns what the platform now reports.  The switch is always written, whatever delivery status the ads underneath report: an ad still in review does not block resuming its campaign. The echoed &#x60;status&#x60; is the confirmation that it landed.  &#x60;updated&#x60; / &#x60;skipped&#x60; describe only the ads whose own status changed alongside it, so &#x60;updated: 0&#x60; is a normal successful response, not a no-op. Ads are skipped when they are in a terminal status (rejected, completed, cancelled), already in the target state, or switched on but not yet delivering. The last group keeps its &#x60;pending_review&#x60; / &#x60;error&#x60; status until the platform reports what it became. &#x60;skippedReasons&#x60; names which case applies.  On Meta this flips the campaign only. An ad set paused in its own right stays paused, so pair this with PUT /v1/ads/ad-sets/{adSetId}/status when you also need the ad set switched back on.  Google keeps an independent on/off switch at campaign, ad group and ad level and the most restrictive one wins, so &#x60;active&#x60; switches the campaign on TOGETHER with the ad groups and ads Zernio tracks under it, in one mutate. Without that the campaign reads ENABLED while a paused ad group or ad keeps it from serving. &#x60;paused&#x60; writes the campaign alone, which already stops delivery and leaves each ad&#39;s own switch as you set it. 
     # @param campaign_id [String] Platform campaign ID
     # @param update_ad_campaign_status_request [UpdateAdCampaignStatusRequest] 
     # @param [Hash] opts the optional parameters
@@ -4176,7 +4188,7 @@ module Zernio
     end
 
     # Update an ad set
-    # Ad-set-level writes. Use this for ABO budget updates, ad-set-scoped pause/resume, bid-strategy edits, Meta value-rule-set attach/detach, and Meta-only post-launch delivery settings via `platformSpecificData`. At least one updatable field is required.  Value rule sets (Meta only, see `/v1/ads/value-rule-sets`): - ATTACH or REPLACE: send `valueRuleSetId`. Attachment is driven by the id's   presence, so `valueRulesApplied: true` is optional. Sending a different id   replaces the previous association; there is no separate replace call. - DETACH: send `valueRulesApplied: false` and OMIT `valueRuleSetId`. - Sending `valueRulesApplied: false` TOGETHER with `valueRuleSetId` returns 400   `mutually_exclusive_fields`. This is deliberate: Meta attaches the rule set   whenever `value_rule_set_id` is present, even with `value_rules_applied` false,   so echoing stored state while asking to detach would silently keep the bid   adjustments live. - Eligibility: only ad sets on `LOWEST_COST_WITHOUT_CAP` or `COST_CAP`. Meta   rejects the rest server-side. - Read back with `GET /v1/ads/ad-sets/{adSetId}?fields=value_rule_set_id`. Meta   does not document `value_rules_applied` as a readable ad-set field, so the   boolean cannot be read back.  Bid strategy compatibility (per Meta's spec): - `LOWEST_COST_WITHOUT_CAP`: no `bidAmount`, no `roasAverageFloor`. - `LOWEST_COST_WITH_BID_CAP` / `COST_CAP`: `bidAmount` REQUIRED (whole currency units). - `LOWEST_COST_WITH_MIN_ROAS`: `roasAverageFloor` REQUIRED (decimal multiplier, e.g. 2.0 = 2.0x ROAS). - Meta only: send `bidAmount` WITHOUT `bidStrategy` to change the cap amount on an ad set   under a COST_CAP / LOWEST_COST_WITH_BID_CAP parent campaign, leaving the strategy itself   (inherited from the campaign) untouched. `roasAverageFloor` without `bidStrategy` is   rejected (it has no meaning outside LOWEST_COST_WITH_MIN_ROAS).  Delivery settings are validated by Meta against the campaign objective; incompatible combinations (e.g. a billingEvent the optimization goal doesn't allow) surface as 400s from Meta.  When updating `budget` on an ABO campaign: if the parent campaign is CBO, the response is 409 with code BUDGET_LEVEL_MISMATCH. Route to PUT /v1/ads/campaigns/{campaignId} instead. 
+    # Ad-set-level writes. Use this for ABO budget updates, ad-set-scoped pause/resume, bid-strategy edits, Meta value-rule-set attach/detach, and Meta-only post-launch delivery settings via `platformSpecificData`. At least one updatable field is required.  Value rule sets (Meta only, see `/v1/ads/value-rule-sets`): - ATTACH or REPLACE: send `valueRuleSetId`. Attachment is driven by the id's   presence, so `valueRulesApplied: true` is optional. Sending a different id   replaces the previous association; there is no separate replace call. - DETACH: send `valueRulesApplied: false` and OMIT `valueRuleSetId`. - Sending `valueRulesApplied: false` TOGETHER with `valueRuleSetId` returns 400   `mutually_exclusive_fields`. This is deliberate: Meta attaches the rule set   whenever `value_rule_set_id` is present, even with `value_rules_applied` false,   so echoing stored state while asking to detach would silently keep the bid   adjustments live. - Eligibility: only ad sets on `LOWEST_COST_WITHOUT_CAP` or `COST_CAP`. Meta   rejects the rest server-side. - Read back with `GET /v1/ads/ad-sets/{adSetId}?fields=value_rule_set_id`. Meta   does not document `value_rules_applied` as a readable ad-set field, so the   boolean cannot be read back.  Bid strategy compatibility (per Meta's spec): - `LOWEST_COST_WITHOUT_CAP`: no `bidAmount`, no `roasAverageFloor`. - `LOWEST_COST_WITH_BID_CAP` / `COST_CAP`: `bidAmount` REQUIRED (whole currency units). - `LOWEST_COST_WITH_MIN_ROAS`: `roasAverageFloor` REQUIRED (decimal multiplier, e.g. 2.0 = 2.0x ROAS). - Meta only: send `bidAmount` WITHOUT `bidStrategy` to change the cap amount on an ad set   under a COST_CAP / LOWEST_COST_WITH_BID_CAP parent campaign, leaving the strategy itself   (inherited from the campaign) untouched. `roasAverageFloor` without `bidStrategy` is   rejected (it has no meaning outside LOWEST_COST_WITH_MIN_ROAS).  Delivery settings are validated by Meta against the campaign objective; incompatible combinations (e.g. a billingEvent the optimization goal doesn't allow) surface as 400s from Meta.  When updating `budget` on an ABO campaign: if the parent campaign is CBO, the response is 409 with code BUDGET_LEVEL_MISMATCH. Route to PUT /v1/ads/campaigns/{campaignId} instead.  `status` behaves exactly as PUT /v1/ads/ad-sets/{adSetId}/status describes, including which child ads each platform writes with the ad set and how `statusUpdated` / `statusSkipped` are counted against the ads' live switches. 
     # @param ad_set_id [String] Platform ad set ID
     # @param update_ad_set_request [UpdateAdSetRequest] 
     # @param [Hash] opts the optional parameters
@@ -4187,7 +4199,7 @@ module Zernio
     end
 
     # Update an ad set
-    # Ad-set-level writes. Use this for ABO budget updates, ad-set-scoped pause/resume, bid-strategy edits, Meta value-rule-set attach/detach, and Meta-only post-launch delivery settings via &#x60;platformSpecificData&#x60;. At least one updatable field is required.  Value rule sets (Meta only, see &#x60;/v1/ads/value-rule-sets&#x60;): - ATTACH or REPLACE: send &#x60;valueRuleSetId&#x60;. Attachment is driven by the id&#39;s   presence, so &#x60;valueRulesApplied: true&#x60; is optional. Sending a different id   replaces the previous association; there is no separate replace call. - DETACH: send &#x60;valueRulesApplied: false&#x60; and OMIT &#x60;valueRuleSetId&#x60;. - Sending &#x60;valueRulesApplied: false&#x60; TOGETHER with &#x60;valueRuleSetId&#x60; returns 400   &#x60;mutually_exclusive_fields&#x60;. This is deliberate: Meta attaches the rule set   whenever &#x60;value_rule_set_id&#x60; is present, even with &#x60;value_rules_applied&#x60; false,   so echoing stored state while asking to detach would silently keep the bid   adjustments live. - Eligibility: only ad sets on &#x60;LOWEST_COST_WITHOUT_CAP&#x60; or &#x60;COST_CAP&#x60;. Meta   rejects the rest server-side. - Read back with &#x60;GET /v1/ads/ad-sets/{adSetId}?fields&#x3D;value_rule_set_id&#x60;. Meta   does not document &#x60;value_rules_applied&#x60; as a readable ad-set field, so the   boolean cannot be read back.  Bid strategy compatibility (per Meta&#39;s spec): - &#x60;LOWEST_COST_WITHOUT_CAP&#x60;: no &#x60;bidAmount&#x60;, no &#x60;roasAverageFloor&#x60;. - &#x60;LOWEST_COST_WITH_BID_CAP&#x60; / &#x60;COST_CAP&#x60;: &#x60;bidAmount&#x60; REQUIRED (whole currency units). - &#x60;LOWEST_COST_WITH_MIN_ROAS&#x60;: &#x60;roasAverageFloor&#x60; REQUIRED (decimal multiplier, e.g. 2.0 &#x3D; 2.0x ROAS). - Meta only: send &#x60;bidAmount&#x60; WITHOUT &#x60;bidStrategy&#x60; to change the cap amount on an ad set   under a COST_CAP / LOWEST_COST_WITH_BID_CAP parent campaign, leaving the strategy itself   (inherited from the campaign) untouched. &#x60;roasAverageFloor&#x60; without &#x60;bidStrategy&#x60; is   rejected (it has no meaning outside LOWEST_COST_WITH_MIN_ROAS).  Delivery settings are validated by Meta against the campaign objective; incompatible combinations (e.g. a billingEvent the optimization goal doesn&#39;t allow) surface as 400s from Meta.  When updating &#x60;budget&#x60; on an ABO campaign: if the parent campaign is CBO, the response is 409 with code BUDGET_LEVEL_MISMATCH. Route to PUT /v1/ads/campaigns/{campaignId} instead. 
+    # Ad-set-level writes. Use this for ABO budget updates, ad-set-scoped pause/resume, bid-strategy edits, Meta value-rule-set attach/detach, and Meta-only post-launch delivery settings via &#x60;platformSpecificData&#x60;. At least one updatable field is required.  Value rule sets (Meta only, see &#x60;/v1/ads/value-rule-sets&#x60;): - ATTACH or REPLACE: send &#x60;valueRuleSetId&#x60;. Attachment is driven by the id&#39;s   presence, so &#x60;valueRulesApplied: true&#x60; is optional. Sending a different id   replaces the previous association; there is no separate replace call. - DETACH: send &#x60;valueRulesApplied: false&#x60; and OMIT &#x60;valueRuleSetId&#x60;. - Sending &#x60;valueRulesApplied: false&#x60; TOGETHER with &#x60;valueRuleSetId&#x60; returns 400   &#x60;mutually_exclusive_fields&#x60;. This is deliberate: Meta attaches the rule set   whenever &#x60;value_rule_set_id&#x60; is present, even with &#x60;value_rules_applied&#x60; false,   so echoing stored state while asking to detach would silently keep the bid   adjustments live. - Eligibility: only ad sets on &#x60;LOWEST_COST_WITHOUT_CAP&#x60; or &#x60;COST_CAP&#x60;. Meta   rejects the rest server-side. - Read back with &#x60;GET /v1/ads/ad-sets/{adSetId}?fields&#x3D;value_rule_set_id&#x60;. Meta   does not document &#x60;value_rules_applied&#x60; as a readable ad-set field, so the   boolean cannot be read back.  Bid strategy compatibility (per Meta&#39;s spec): - &#x60;LOWEST_COST_WITHOUT_CAP&#x60;: no &#x60;bidAmount&#x60;, no &#x60;roasAverageFloor&#x60;. - &#x60;LOWEST_COST_WITH_BID_CAP&#x60; / &#x60;COST_CAP&#x60;: &#x60;bidAmount&#x60; REQUIRED (whole currency units). - &#x60;LOWEST_COST_WITH_MIN_ROAS&#x60;: &#x60;roasAverageFloor&#x60; REQUIRED (decimal multiplier, e.g. 2.0 &#x3D; 2.0x ROAS). - Meta only: send &#x60;bidAmount&#x60; WITHOUT &#x60;bidStrategy&#x60; to change the cap amount on an ad set   under a COST_CAP / LOWEST_COST_WITH_BID_CAP parent campaign, leaving the strategy itself   (inherited from the campaign) untouched. &#x60;roasAverageFloor&#x60; without &#x60;bidStrategy&#x60; is   rejected (it has no meaning outside LOWEST_COST_WITH_MIN_ROAS).  Delivery settings are validated by Meta against the campaign objective; incompatible combinations (e.g. a billingEvent the optimization goal doesn&#39;t allow) surface as 400s from Meta.  When updating &#x60;budget&#x60; on an ABO campaign: if the parent campaign is CBO, the response is 409 with code BUDGET_LEVEL_MISMATCH. Route to PUT /v1/ads/campaigns/{campaignId} instead.  &#x60;status&#x60; behaves exactly as PUT /v1/ads/ad-sets/{adSetId}/status describes, including which child ads each platform writes with the ad set and how &#x60;statusUpdated&#x60; / &#x60;statusSkipped&#x60; are counted against the ads&#39; live switches. 
     # @param ad_set_id [String] Platform ad set ID
     # @param update_ad_set_request [UpdateAdSetRequest] 
     # @param [Hash] opts the optional parameters
@@ -4250,7 +4262,7 @@ module Zernio
     end
 
     # Pause or resume a single ad set
-    # Ad-set-scoped pause/resume (doesn't touch sibling ad sets). Thin wrapper over PUT /v1/ads/ad-sets/{adSetId} for callers that only want the status toggle and prefer a symmetric URL to /v1/ads/campaigns/{campaignId}/status.  Writes the ad set's own on/off switch on every platform (Meta `configured_status`, TikTok ad group `operation_status`, Google ad group status, LinkedIn campaign, Pinterest ad group, X line item, OpenAI ad group), whatever delivery status its ads report: an ad still in review or paused by its campaign does not block it. The echoed `status` is the confirmation that it landed. On TikTok, Pinterest and OpenAI the ads whose own switch is not yet in the target state are flipped with it.  `updated` / `skipped` describe only the ads whose own stored status CHANGED alongside the switch, so `updated: 0` is a normal successful response. See `skippedReasons` for which of the three cases applies (terminal, already in the target state, or switched on but not yet delivering).  A campaign created paused needs its campaign resumed as well: pair this with PUT /v1/ads/campaigns/{campaignId}/status. 
+    # Ad-set-scoped pause/resume (doesn't touch sibling ad sets). Thin wrapper over PUT /v1/ads/ad-sets/{adSetId} for callers that only want the status toggle and prefer a symmetric URL to /v1/ads/campaigns/{campaignId}/status.  Writes the ad set's own on/off switch on every platform (Meta `configured_status`, TikTok ad group `operation_status`, Google ad group status, LinkedIn campaign, Pinterest ad group, X line item, OpenAI ad group), whatever delivery status its ads report: an ad still in review or paused by its campaign does not block it. The echoed `status` is the confirmation that it landed.  **What the write touches (current semantics, per platform).** On TikTok the ad group AND every ad under it that is not in a terminal status (rejected, completed, cancelled) are written to the target state, on pause and on resume alike, so a resume also switches those ads on. Pinterest and ChatGPT (OpenAI) do the same with their ads. On Meta, Google, LinkedIn (campaign) and X (line item) only the ad set's own switch is written and each ad keeps its own switch.  **Counts and readback.** Before the write, each ad's own switch is read live from the platform (up to 20 ads; beyond that the stored switch is used), and `updated` / `skipped` are computed against that live state, not against a stored switch a change in the platform's UI may have left stale. After the write each ad's own switch and delivery status are read again and stored, and the ad set switch is re-read and stored, so an immediate GET returns what the platform now reports.  `updated` / `skipped` describe only the ads whose own status changed alongside the switch, so `updated: 0` is a normal successful response. See `skippedReasons` for which of the three cases applies (terminal, own switch already in the target state, or switched on but not yet delivering).  A campaign created paused needs its campaign resumed as well: pair this with PUT /v1/ads/campaigns/{campaignId}/status. 
     # @param ad_set_id [String] Platform ad set ID
     # @param update_ad_campaign_status_request [UpdateAdCampaignStatusRequest] 
     # @param [Hash] opts the optional parameters
@@ -4261,7 +4273,7 @@ module Zernio
     end
 
     # Pause or resume a single ad set
-    # Ad-set-scoped pause/resume (doesn&#39;t touch sibling ad sets). Thin wrapper over PUT /v1/ads/ad-sets/{adSetId} for callers that only want the status toggle and prefer a symmetric URL to /v1/ads/campaigns/{campaignId}/status.  Writes the ad set&#39;s own on/off switch on every platform (Meta &#x60;configured_status&#x60;, TikTok ad group &#x60;operation_status&#x60;, Google ad group status, LinkedIn campaign, Pinterest ad group, X line item, OpenAI ad group), whatever delivery status its ads report: an ad still in review or paused by its campaign does not block it. The echoed &#x60;status&#x60; is the confirmation that it landed. On TikTok, Pinterest and OpenAI the ads whose own switch is not yet in the target state are flipped with it.  &#x60;updated&#x60; / &#x60;skipped&#x60; describe only the ads whose own stored status CHANGED alongside the switch, so &#x60;updated: 0&#x60; is a normal successful response. See &#x60;skippedReasons&#x60; for which of the three cases applies (terminal, already in the target state, or switched on but not yet delivering).  A campaign created paused needs its campaign resumed as well: pair this with PUT /v1/ads/campaigns/{campaignId}/status. 
+    # Ad-set-scoped pause/resume (doesn&#39;t touch sibling ad sets). Thin wrapper over PUT /v1/ads/ad-sets/{adSetId} for callers that only want the status toggle and prefer a symmetric URL to /v1/ads/campaigns/{campaignId}/status.  Writes the ad set&#39;s own on/off switch on every platform (Meta &#x60;configured_status&#x60;, TikTok ad group &#x60;operation_status&#x60;, Google ad group status, LinkedIn campaign, Pinterest ad group, X line item, OpenAI ad group), whatever delivery status its ads report: an ad still in review or paused by its campaign does not block it. The echoed &#x60;status&#x60; is the confirmation that it landed.  **What the write touches (current semantics, per platform).** On TikTok the ad group AND every ad under it that is not in a terminal status (rejected, completed, cancelled) are written to the target state, on pause and on resume alike, so a resume also switches those ads on. Pinterest and ChatGPT (OpenAI) do the same with their ads. On Meta, Google, LinkedIn (campaign) and X (line item) only the ad set&#39;s own switch is written and each ad keeps its own switch.  **Counts and readback.** Before the write, each ad&#39;s own switch is read live from the platform (up to 20 ads; beyond that the stored switch is used), and &#x60;updated&#x60; / &#x60;skipped&#x60; are computed against that live state, not against a stored switch a change in the platform&#39;s UI may have left stale. After the write each ad&#39;s own switch and delivery status are read again and stored, and the ad set switch is re-read and stored, so an immediate GET returns what the platform now reports.  &#x60;updated&#x60; / &#x60;skipped&#x60; describe only the ads whose own status changed alongside the switch, so &#x60;updated: 0&#x60; is a normal successful response. See &#x60;skippedReasons&#x60; for which of the three cases applies (terminal, own switch already in the target state, or switched on but not yet delivering).  A campaign created paused needs its campaign resumed as well: pair this with PUT /v1/ads/campaigns/{campaignId}/status. 
     # @param ad_set_id [String] Platform ad set ID
     # @param update_ad_campaign_status_request [UpdateAdCampaignStatusRequest] 
     # @param [Hash] opts the optional parameters

data/lib/zernio-sdk/api/ad_creatives_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/ad_insights_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/ad_library_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/ad_targeting_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/analytics_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/api_keys_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/blogs_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/branded_calling_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/broadcasts_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/business_agent_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/calls_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/comment_automations_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/comments_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/connect_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/connected_apps_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/contacts_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/conversions_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/custom_fields_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/discord_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/feedback_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/gmb_attributes_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/gmb_food_menus_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/gmb_location_details_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/gmb_media_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/gmb_place_actions_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/gmb_reviews_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/gmb_services_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/gmb_verifications_api.rb

@@ -3,7 +3,7 @@
 
 #API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema).  Request ids: responses carry an X-Request-Id header with the id we log the request under. Quote it when reporting a problem. A valid x-request-id you send is reused as that id. 
 
-The version of the OpenAPI document: 1.146.2
+The version of the OpenAPI document: 1.147.1
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0