late-sdk 0.0.1228 → 0.0.1230

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1a6e6a1b8cfccd822c8e0b9bc4662f5e59761ff7df003fb690ca63756c6ca5e3
-  data.tar.gz: 1793442683937deb851175cbcf90d19db57a9694f029b1db5de985b2a1c4706a
+  metadata.gz: 91f3a4ca84aab00a8d63bf969eefdf58746d988d6250fbdd87469a79dc115ece
+  data.tar.gz: 6dcd40dd4f5b0291c52bcccabeba0358d60bc128fc3ec9cd1e0bda6cd87fb888
 SHA512:
-  metadata.gz: d091bb4dd48eddbb4ea5dab8f27496690eeb9035968524cee4fbf00dd93528f4ab388db04f171ec96b7298a147062378853a1c979d63f9d2a4fdd8813034964b
-  data.tar.gz: 892ddbf804f1c74a826cbec10c39324814fc80f8b460cf489d149f69808689c0d2790cb265b60fa2a02bc07aef24fc665c6a580cf563470edd317e50725c7863
+  metadata.gz: ad4211ed74207d6125e1648f5953b3b3b13027a813c1a0ecf8b3ead0a4760821311ebf897c65c369145372d544030974de7275ebabf55ff4911af91e9ef6bb1c
+  data.tar.gz: 2826ad51b0d332160ebf523af70be77c26cfcd901c6f66299aaa6d983af8287d5d1632c0d532a9ae19b8009190b648b88c92b24f9203f57ab064757920f4eb05

data/README.md

@@ -21,7 +21,7 @@ send is reused as that id.
 
 This SDK is automatically generated by the [OpenAPI Generator](https://openapi-generator.tech) project:
 
-- API version: 1.177.0
+- API version: 1.179.0
 - Package version: 0.1.0
 - Generator version: 7.19.0
 - Build package: org.openapitools.codegen.languages.RubyClientCodegen

data/docs/AdTargetingApi.md

@@ -295,7 +295,7 @@ end
 
 Search targeting options
 
-Resolve a human-readable query into the platform's opaque targeting ids used in the `TargetingSpec` (`countries`/`regions`/`cities`/`zips`/`metros` geo keys, and `interests`/`behaviors` entity ids) on `POST /v1/ads/create`, `POST /v1/ads/targeting/reach-estimate`, and `saved_targeting` audiences.  The `dimension` param selects what is searched:  - `geo`: locations, further scoped by `geoType` - `interest` - `behavior`: Meta-only, matched by name against Meta's fixed behaviors catalog   (e.g. `Small business owners`, `Frequent Travelers`); ids feed `TargetingSpec.behaviors` - `income`: the household-income tiers the platform can target (Meta, TikTok, Google).   The id is the normalized tier (`top_5`, `top_10`, `top_10_25`, `top_25_50`) to pass as   `TargetingSpec.incomeTier`, never a platform segment id. Meta's tiers are US-only   ZIP-code percentiles (label and `audienceSize` come live from Meta), TikTok expresses all   four and Google only `top_10`. `q` is matched against the label, so `top` or `income`   lists every tier - `language`: Google-only - `workPosition`, `workEmployer`, `workIndustry`: the Meta-only work demographics, whose   ids feed `TargetingSpec.workPositions`/`workEmployers`/`workIndustries` - `industry`, `jobFunction`, `seniority`, `companySize`: the LinkedIn-only B2B facets, whose   URNs feed `TargetingSpec.industries`/`jobFunctions`/`seniorities`/`companySizes`  Availability of each dimension varies by platform. A dimension a platform cannot search returns a 400 naming `dimension`; it never falls back to another dimension, and every result's `type` is the requested dimension (or the geo level for `geo`).  TikTok `interest` searches TikTok's interest category catalog (about 700 categories over four levels, `path` holds the parent categories), matched by name in Zernio. The ids are what `TargetingSpec.interests` sends to TikTok as `interest_category_ids`. Work industries are a fixed ~30-entry Meta catalog with no server-side query, so `workIndustry` matching, ranking and `limit` happen in Zernio. `language` is likewise a fixed, checked-in table of Google's targetable `language_constant` rows (id, ISO code, name) matched by name or code, capped at 20, with no network call; its ids feed `TargetingSpec.languages`.  Results are normalized across platforms into a single shape, so the same client code consumes Meta, TikTok, LinkedIn, X, Pinterest, and Google results.  TikTok geo searches return every matching level in one list (`type` is `country`, `region`, `city`, `district`, or `metro` for DMA areas), and `geoType` is not applied. Results are scoped to the advertiser's targetable markets. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is TikTok's numeric location id, usable in `regions`/`cities`/`metros` keys on `POST /v1/ads/create`.  LinkedIn geo searches also return every matching level in one list, and neither `geoType` nor `countryCode` is applied: LinkedIn's typeahead only returns a name and a URN per result, with no level or country field to filter on. A result whose URN is a country Zernio holds a code for has `type: country` and its ISO 3166-1 alpha-2 code as the id, for `targeting.countries`. Every other result has `type: region` and keeps its `urn:li:geo:*` URN as the id, usable as a `regions[].key` on `POST /v1/ads/create`, `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate` (LinkedIn puts countries and regions in the same `locations` facet, so both target the same way).  LinkedIn B2B searches (`industry`, `jobFunction`, `seniority`, `companySize`) return the full URN to pass straight back, so no URN id fragment has to be assembled by hand: `urn:li:industry:4`, `urn:li:function:8`, `urn:li:seniority:6`, `urn:li:staffCountRange:(51,200)`. Only `industry` is a server-side name search (LinkedIn's typeahead finder). LinkedIn exposes no typeahead for job functions, seniorities and company sizes, so Zernio fetches each whole table (26, 10 and 9 entries), caches it, and does the matching, ranking and `limit` cutoff itself. Those three never carry `audienceSize`, and `countryCode` and `geoType` are not applied to any of the four.  Google geo searches resolve against Google's geoTargetConstants and return every matching level in one list; `geoType` is not applied (Google's `target_type` is an open taxonomy that does not map one-to-one onto the `geoType` enum), so filter client-side on the returned `type` (`country`, `region`, `city`, `zip`, `metro`, or the lowercased Google target type for rarer levels). `countryCode` scopes the search to one country. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is Google's numeric criterion id, usable as a `regions`/`cities`/`zips`/`metros` `key` on `POST /v1/ads/create`. Google city radius is not supported (pass a `customLocations` lat/lng pin for a radius); country targeting also accepts plain ISO codes via `countries` with no search call.  Pinterest resolves against three whole-catalog endpoints (interests, locations, regions) with no server-side query or pagination, so matching, ranking and the `limit` cutoff all happen in Zernio; the catalog is independent of any ad account and results never carry `audienceSize`. Names come back localized to the connected Pinterest account's language (there is no way to force a locale), so match against whatever language that account returns.  `geoType` routes to a different Pinterest catalog:  - `country` and `metro_area` read the locations catalog (`type` is `country` or `metro`) - `region` reads the regions catalog (`type` is `region`, its id a `regions[].key` on   `POST /v1/ads/create`) - `all` and the default `city` merge both catalogs with honest per-entry `type`s, since   Pinterest has no city-level catalog and `city` is an alias for `all`, not a literal   city search - `zip`, `subcity`, `neighborhood`, `place` and `geo_market` return a 400: Pinterest   exposes no postal-code catalog, pass postal codes directly as   `targeting.zips: [{ key }]` on `POST /v1/ads/create`  For geo queries, `q` should contain only the locality name (e.g. `\"Amsterdam\"`, not `\"Amsterdam, NL\"`). Use `countryCode` to disambiguate. 
+Resolve a human-readable query into the platform's opaque targeting ids used in the `TargetingSpec` (`countries`/`regions`/`cities`/`zips`/`metros` geo keys, and `interests`/`behaviors` entity ids) on `POST /v1/ads/create`, `POST /v1/ads/targeting/reach-estimate`, and `saved_targeting` audiences.  The `dimension` param selects what is searched:  - `geo`: locations, further scoped by `geoType` - `interest` - `behavior`: Meta and TikTok, matched by name; ids feed `TargetingSpec.behaviors`.   Meta: its fixed behaviors catalog (e.g. `Small business owners`, `Frequent Travelers`).   TikTok: video and creator interaction categories (e.g. `Software & Apps`), with ids like   `video:1913101` or `creator:24001` and `path` starting with `Video interactions` or   `Creator interactions` - `income`: the household-income tiers the platform can target (Meta, TikTok, Google).   The id is the normalized tier (`top_5`, `top_10`, `top_10_25`, `top_25_50`) to pass as   `TargetingSpec.incomeTier`, never a platform segment id. Meta's tiers are US-only   ZIP-code percentiles (label and `audienceSize` come live from Meta), TikTok expresses all   four and Google only `top_10`. `q` is matched against the label, so `top` or `income`   lists every tier - `language`: Google-only - `workPosition`, `workEmployer`, `workIndustry`: the Meta-only work demographics, whose   ids feed `TargetingSpec.workPositions`/`workEmployers`/`workIndustries` - `industry`, `jobFunction`, `seniority`, `companySize`: the LinkedIn-only B2B facets, whose   URNs feed `TargetingSpec.industries`/`jobFunctions`/`seniorities`/`companySizes`  Availability of each dimension varies by platform. A dimension a platform cannot search returns a 400 naming `dimension`; it never falls back to another dimension, and every result's `type` is the requested dimension (or the geo level for `geo`).  TikTok `interest` searches TikTok's interest category catalog (about 700 categories over four levels, `path` holds the parent categories), matched by name in Zernio. The ids are what `TargetingSpec.interests` sends to TikTok as `interest_category_ids`. Work industries are a fixed ~30-entry Meta catalog with no server-side query, so `workIndustry` matching, ranking and `limit` happen in Zernio. `language` is likewise a fixed, checked-in table of Google's targetable `language_constant` rows (id, ISO code, name) matched by name or code, capped at 20, with no network call; its ids feed `TargetingSpec.languages`.  Results are normalized across platforms into a single shape, so the same client code consumes Meta, TikTok, LinkedIn, X, Pinterest, and Google results.  TikTok geo searches return every matching level in one list (`type` is `country`, `region`, `city`, `district`, or `metro` for DMA areas), and `geoType` is not applied. Results are scoped to the advertiser's targetable markets. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is TikTok's numeric location id, usable in `regions`/`cities`/`metros` keys on `POST /v1/ads/create`.  LinkedIn geo searches also return every matching level in one list, and neither `geoType` nor `countryCode` is applied: LinkedIn's typeahead only returns a name and a URN per result, with no level or country field to filter on. A result whose URN is a country Zernio holds a code for has `type: country` and its ISO 3166-1 alpha-2 code as the id, for `targeting.countries`. Every other result has `type: region` and keeps its `urn:li:geo:*` URN as the id, usable as a `regions[].key` on `POST /v1/ads/create`, `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate` (LinkedIn puts countries and regions in the same `locations` facet, so both target the same way).  LinkedIn B2B searches (`industry`, `jobFunction`, `seniority`, `companySize`) return the full URN to pass straight back, so no URN id fragment has to be assembled by hand: `urn:li:industry:4`, `urn:li:function:8`, `urn:li:seniority:6`, `urn:li:staffCountRange:(51,200)`. Only `industry` is a server-side name search (LinkedIn's typeahead finder). LinkedIn exposes no typeahead for job functions, seniorities and company sizes, so Zernio fetches each whole table (26, 10 and 9 entries), caches it, and does the matching, ranking and `limit` cutoff itself. Those three never carry `audienceSize`, and `countryCode` and `geoType` are not applied to any of the four.  Google geo searches resolve against Google's geoTargetConstants and return every matching level in one list; `geoType` is not applied (Google's `target_type` is an open taxonomy that does not map one-to-one onto the `geoType` enum), so filter client-side on the returned `type` (`country`, `region`, `city`, `zip`, `metro`, or the lowercased Google target type for rarer levels). `countryCode` scopes the search to one country. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is Google's numeric criterion id, usable as a `regions`/`cities`/`zips`/`metros` `key` on `POST /v1/ads/create`. Google city radius is not supported (pass a `customLocations` lat/lng pin for a radius); country targeting also accepts plain ISO codes via `countries` with no search call.  Pinterest resolves against three whole-catalog endpoints (interests, locations, regions) with no server-side query or pagination, so matching, ranking and the `limit` cutoff all happen in Zernio; the catalog is independent of any ad account and results never carry `audienceSize`. Names come back localized to the connected Pinterest account's language (there is no way to force a locale), so match against whatever language that account returns.  `geoType` routes to a different Pinterest catalog:  - `country` and `metro_area` read the locations catalog (`type` is `country` or `metro`) - `region` reads the regions catalog (`type` is `region`, its id a `regions[].key` on   `POST /v1/ads/create`) - `all` and the default `city` merge both catalogs with honest per-entry `type`s, since   Pinterest has no city-level catalog and `city` is an alias for `all`, not a literal   city search - `zip`, `subcity`, `neighborhood`, `place` and `geo_market` return a 400: Pinterest   exposes no postal-code catalog, pass postal codes directly as   `targeting.zips: [{ key }]` on `POST /v1/ads/create`  For geo queries, `q` should contain only the locality name (e.g. `\"Amsterdam\"`, not `\"Amsterdam, NL\"`). Use `countryCode` to disambiguate. 
 
 ### Examples
 

data/docs/CommentAutomationAudience.md

@@ -7,6 +7,7 @@
 | **follower_status** | **String** |  | [optional][default to 'any'] |
 | **min_follower_count** | **Integer** | Skip commenters with fewer followers than this. Omit for no size rule. | [optional] |
 | **when_unknown** | **String** | What to do when Instagram will not reveal the follow relationship.   * `send` (default) - deliver the DM anyway (fails open).   * `skip` - stay silent.   * `verify` - send `followGate.message` with a confirm button. Tapping it is a     message, which grants consent, so the re-check on the tap resolves and the     real DM (or `followGate.notFollowingMessage`) follows automatically.  | [optional][default to 'send'] |
+| **tap_to_unlock** | **Boolean** | Send `followGate.message` with its button to EVERY commenter and deliver the real DM when they tap it, with no follow check at any point. Cannot be combined with a `followerStatus` other than `any` or with `minFollowerCount` (400); `whenUnknown` is ignored. Instagram only. A PATCH that sends `audience` without this field clears it.  | [optional][default to false] |
 
 ## Example
 
@@ -16,7 +17,8 @@ require 'zernio-sdk'
 instance = Zernio::CommentAutomationAudience.new(
   follower_status: null,
   min_follower_count: null,
-  when_unknown: null
+  when_unknown: null,
+  tap_to_unlock: null
 )
 ```
 

data/docs/CommentAutomationFollowGate.md

@@ -4,8 +4,8 @@
 
 | Name | Type | Description | Notes |
 | ---- | ---- | ----------- | ----- |
-| **message** | **String** | Confirmation DM sent when whenUnknown=verify. | [optional] |
-| **button_label** | **String** | Confirm button label. Defaults to \"I'm following\". | [optional] |
+| **message** | **String** | Confirmation DM sent when whenUnknown=verify or tapToUnlock=true. The default copy asks for a follow under whenUnknown=verify and only for the tap under tapToUnlock. | [optional] |
+| **button_label** | **String** | Confirm button label. Defaults to \"I'm following\" (whenUnknown=verify) or \"Unlock\" (tapToUnlock). | [optional] |
 | **not_following_message** | **String** | Sent to a commenter we know does not follow (followerStatus=follower), and after a confirm tap that does not unlock the DM. When following is what would unlock it, the message carries the confirm button so they can re-check once they follow; above 640 characters it goes out as plain text without the button. Omit to stay silent on a keyword comment; a confirm tap always gets an answer (a default message is used). | [optional] |
 
 ## Example

data/docs/CommentAutomationsApi.md

@@ -18,7 +18,7 @@ All URIs are relative to *https://zernio.com/api*
 
 Create comment-to-DM automation
 
-Create a keyword-triggered DM automation on an Instagram or Facebook account. When someone comments a matching keyword (or, with `trigger: story_reply`, replies to your Instagram story with one), they automatically receive a DM.  To continue into a specific workflow after the recipient taps a button, use `{\"type\":\"postback\",\"title\":\"Send it\",\"payload\":\"zernio:workflow:<workflowId>\"}`. The target must be active and belong to the same account and profile. This also works for product-card buttons. The tap starts that workflow directly, without matching its keyword or first-message condition. A different live workflow in the conversation is exited; tapping the same live workflow does not restart it or consume a pending reply. Stale or invalid targets do nothing. The initial comment DM alone does not start the workflow: the recipient must tap.  Triggers (`trigger`):   * `comment` (default): fires on keyword comments on a post or reel.   * `story_reply`: fires when someone replies to your Instagram story with a keyword,     and answers them with a DM. Set `platformPostId` to a story media id to scope to     one story, or omit it to match replies to any story.  Targeting (comment trigger):   * Per-post: set `platformPostId` to scope to one specific post (only one active     per-post automation is allowed per post).   * Account-wide (\"any post\"): omit `platformPostId` (and `postId`). The automation     evaluates every comment on every post on the account. You can stack unlimited     account-wide automations, each with its own keyword set, and they all run     independently. Per-post automations take priority on their post.  Audience (`audience`, Instagram only): restrict the automation to followers or non-followers, and/or to accounts above a follower count. Instagram only reveals the follow relationship for people who have messaged the account, so `audience.whenUnknown` decides what happens for everyone else - including `verify`, which sends a one-tap confirmation DM (`followGate`) and then delivers the real DM automatically. People we already know follow you skip the tap entirely.  Set `alsoMatchInDms: true` on a `comment` automation to also answer people who send a keyword as a direct message instead of commenting it. One automation then covers both doors, and each door is deduplicated separately (someone who already got the DM from their comment still gets it if they later DM the keyword). Requires at least one keyword.  Links in the DM's buttons can be click-tracked (`linkTracking`, on by default) and clickers optionally tagged (`clickTag`) for segmentation. Stats returned include delivered, read, and link clicks. 
+Create a keyword-triggered DM automation on an Instagram or Facebook account. When someone comments a matching keyword (or, with `trigger: story_reply`, replies to your Instagram story with one), they automatically receive a DM.  To continue into a specific workflow after the recipient taps a button, use `{\"type\":\"postback\",\"title\":\"Send it\",\"payload\":\"zernio:workflow:<workflowId>\"}`. The target must be active and belong to the same account and profile. This also works for product-card buttons. The tap starts that workflow directly, without matching its keyword or first-message condition. A different live workflow in the conversation is exited; tapping the same live workflow does not restart it or consume a pending reply. Stale or invalid targets do nothing. The initial comment DM alone does not start the workflow: the recipient must tap.  Triggers (`trigger`):   * `comment` (default): fires on keyword comments on a post or reel.   * `story_reply`: fires when someone replies to your Instagram story with a keyword,     and answers them with a DM. Set `platformPostId` to a story media id to scope to     one story, or omit it to match replies to any story.  Targeting (comment trigger):   * Per-post: set `platformPostId` to scope to one specific post (only one active     per-post automation is allowed per post).   * Account-wide (\"any post\"): omit `platformPostId` (and `postId`). The automation     evaluates every comment on every post on the account. You can stack unlimited     account-wide automations, each with its own keyword set, and they all run     independently. Per-post automations take priority on their post.  Audience (`audience`, Instagram only): restrict the automation to followers or non-followers, and/or to accounts above a follower count. Instagram only reveals the follow relationship for people who have messaged the account, so `audience.whenUnknown` decides what happens for everyone else - including `verify`, which sends a one-tap confirmation DM (`followGate`) and then delivers the real DM automatically. People we already know follow you skip the tap entirely. Set `audience.tapToUnlock: true` instead to send that button DM to every commenter and deliver the real DM on the tap with no follow check.  Set `alsoMatchInDms: true` on a `comment` automation to also answer people who send a keyword as a direct message instead of commenting it. One automation then covers both doors, and each door is deduplicated separately (someone who already got the DM from their comment still gets it if they later DM the keyword). Requires at least one keyword.  Links in the DM's buttons can be click-tracked (`linkTracking`, on by default) and clickers optionally tagged (`clickTag`) for segmentation. Stats returned include delivered, read, and link clicks. 
 
 ### Examples
 

data/docs/CreateCallAdRequest.md

@@ -48,7 +48,7 @@
 | **places** | [**Array<CtwaAdRequestBodyPlacesInner>**](CtwaAdRequestBodyPlacesInner.md) | Meta place keys (from GET /v1/ads/targeting/search). | [optional] |
 | **neighborhoods** | [**Array<CtwaAdRequestBodyPlacesInner>**](CtwaAdRequestBodyPlacesInner.md) | Meta neighborhood keys (from GET /v1/ads/targeting/search). | [optional] |
 | **excluded_locations** | **Hash<String, Object>** | Geo to exclude, same shape as POST /v1/ads/create (countries, countryGroups, regions, cities, zips, places, neighborhoods, customLocations). | [optional] |
-| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Meta behavior ids. Each dimension is its own flexible_spec entry: OR within, AND across. | [optional] |
+| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Behavior ids from /v1/ads/targeting/search?dimension=behavior. Meta: each dimension is its own flexible_spec entry (OR within, AND across). TikTok: video/creator interaction categories, sent as the ad group's actions. | [optional] |
 | **work_positions** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) |  | [optional] |
 | **work_employers** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) |  | [optional] |
 | **work_industries** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) |  | [optional] |

data/docs/CreateMessagingAdRequest.md

@@ -48,7 +48,7 @@
 | **places** | [**Array<CtwaAdRequestBodyPlacesInner>**](CtwaAdRequestBodyPlacesInner.md) | Meta place keys (from GET /v1/ads/targeting/search). | [optional] |
 | **neighborhoods** | [**Array<CtwaAdRequestBodyPlacesInner>**](CtwaAdRequestBodyPlacesInner.md) | Meta neighborhood keys (from GET /v1/ads/targeting/search). | [optional] |
 | **excluded_locations** | **Hash<String, Object>** | Geo to exclude, same shape as POST /v1/ads/create (countries, countryGroups, regions, cities, zips, places, neighborhoods, customLocations). | [optional] |
-| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Meta behavior ids. Each dimension is its own flexible_spec entry: OR within, AND across. | [optional] |
+| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Behavior ids from /v1/ads/targeting/search?dimension=behavior. Meta: each dimension is its own flexible_spec entry (OR within, AND across). TikTok: video/creator interaction categories, sent as the ad group's actions. | [optional] |
 | **work_positions** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) |  | [optional] |
 | **work_employers** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) |  | [optional] |
 | **work_industries** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) |  | [optional] |

data/docs/CreateStandaloneAdRequest.md

@@ -58,7 +58,7 @@
 | **zips** | [**Array<CreateStandaloneAdRequestZipsInner>**](CreateStandaloneAdRequestZipsInner.md) | Postal/ZIP geo targeting. `key` is the platform's postal location ID from /v1/ads/targeting/search?dimension=geo&geoType=zip. Supported on Meta, Google, TikTok, Pinterest, X. | [optional] |
 | **metros** | [**Array<CreateStandaloneAdRequestZipsInner>**](CreateStandaloneAdRequestZipsInner.md) | DMA / metro-area geo targeting (Meta and TikTok). `key` is the platform's metro ID from /v1/ads/targeting/search?dimension=geo&geoType=metro (TikTok metros appear as type `metro`, e.g. the New York DMA). | [optional] |
 | **custom_locations** | [**Array<CreateStandaloneAdRequestCustomLocationsInner>**](CreateStandaloneAdRequestCustomLocationsInner.md) | Point-radius (lat/lng) geo targeting. Meta only (custom_locations). Rejected on platforms without radius support. | [optional] |
-| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Behaviour entities from /v1/ads/targeting/search?dimension=behavior. Supported on Meta only (TikTok behaviours are rejected with a 400). Each must include id. | [optional] |
+| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Behaviour entities from /v1/ads/targeting/search?dimension=behavior (Meta and TikTok). On TikTok they target people who interacted with videos (watched to the end, liked, commented or shared, last 15 days) or creators (followed or viewed the profile) in the picked categories, and the ad group uses the TikTok placement only. Each must include id. | [optional] |
 | **work_positions** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Meta only. Job title entities from /v1/ads/targeting/search?dimension=workPosition. Each must include id. Rejected on other platforms (use LinkedIn's `jobTitles` there). | [optional] |
 | **work_employers** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Meta only. Employer entities from /v1/ads/targeting/search?dimension=workEmployer. Each must include id. | [optional] |
 | **work_industries** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Meta only. Work-industry entities from /v1/ads/targeting/search?dimension=workIndustry. Each must include id. Rejected on other platforms (use LinkedIn's `industries` there). | [optional] |

data/docs/CtwaAdRequestBody.md

@@ -48,7 +48,7 @@
 | **places** | [**Array<CtwaAdRequestBodyPlacesInner>**](CtwaAdRequestBodyPlacesInner.md) | Meta place keys (from GET /v1/ads/targeting/search). | [optional] |
 | **neighborhoods** | [**Array<CtwaAdRequestBodyPlacesInner>**](CtwaAdRequestBodyPlacesInner.md) | Meta neighborhood keys (from GET /v1/ads/targeting/search). | [optional] |
 | **excluded_locations** | **Hash<String, Object>** | Geo to exclude, same shape as POST /v1/ads/create (countries, countryGroups, regions, cities, zips, places, neighborhoods, customLocations). | [optional] |
-| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Meta behavior ids. Each dimension is its own flexible_spec entry: OR within, AND across. | [optional] |
+| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Behavior ids from /v1/ads/targeting/search?dimension=behavior. Meta: each dimension is its own flexible_spec entry (OR within, AND across). TikTok: video/creator interaction categories, sent as the ad group's actions. | [optional] |
 | **work_positions** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) |  | [optional] |
 | **work_employers** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) |  | [optional] |
 | **work_industries** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) |  | [optional] |

data/docs/TargetingSpec.md

@@ -20,7 +20,7 @@
 | **income_tier** | **String** | Normalized household-income tier (ZIP/percentile based). Meta and TikTok express all four. Google maps only `top_10` (its INCOME_RANGE_90_UP); other tiers on Google, and any income tier on LinkedIn / X / Pinterest, are rejected. On Meta, income/zip targeting requires the relevant `specialAdCategories` to be unset (housing/employment/credit ads cannot use it).  | [optional] |
 | **languages** | **Array<String>** | Language codes restricting the audience by language. On Meta, ISO 639-1 codes (e.g. ['en']); a bare code targets all regional variants (\"en\" = all English), or use a region-qualified code (\"en_GB\", \"pt_BR\") for a specific one. Unknown codes are rejected. | [optional] |
 | **interests** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Interest entities from /v1/ads/targeting/search?dimension=interest. Each carries the platform's opaque id. | [optional] |
-| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Behaviour entities from /v1/ads/targeting/search?dimension=behavior. Supported on Meta only (TikTok behaviours are rejected with a 400). | [optional] |
+| **behaviors** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Behaviour entities from /v1/ads/targeting/search?dimension=behavior (Meta and TikTok). On TikTok they target people who interacted with videos (watched to the end, liked, commented or shared, last 15 days) or creators (followed or viewed the profile) in the picked categories, and the ad group uses the TikTok placement only. | [optional] |
 | **work_positions** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Meta only. Job title entities from /v1/ads/targeting/search?dimension=workPosition. Not interchangeable with the LinkedIn `jobTitles` URN fragments. | [optional] |
 | **work_employers** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Meta only. Employer entities from /v1/ads/targeting/search?dimension=workEmployer. | [optional] |
 | **work_industries** | [**Array<CreateStandaloneAdRequestBehaviorsInner>**](CreateStandaloneAdRequestBehaviorsInner.md) | Meta only. Work-industry entities from /v1/ads/targeting/search?dimension=workIndustry. Not interchangeable with the LinkedIn `industries` URN fragments. | [optional] |

data/late-sdk.gemspec

@@ -5,7 +5,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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/account_groups_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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/account_settings_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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/accounts_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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/ad_accounts_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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/ad_audiences_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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0
@@ -295,7 +295,7 @@ module Zernio
     end
 
     # Search targeting options
-    # Resolve a human-readable query into the platform's opaque targeting ids used in the `TargetingSpec` (`countries`/`regions`/`cities`/`zips`/`metros` geo keys, and `interests`/`behaviors` entity ids) on `POST /v1/ads/create`, `POST /v1/ads/targeting/reach-estimate`, and `saved_targeting` audiences.  The `dimension` param selects what is searched:  - `geo`: locations, further scoped by `geoType` - `interest` - `behavior`: Meta-only, matched by name against Meta's fixed behaviors catalog   (e.g. `Small business owners`, `Frequent Travelers`); ids feed `TargetingSpec.behaviors` - `income`: the household-income tiers the platform can target (Meta, TikTok, Google).   The id is the normalized tier (`top_5`, `top_10`, `top_10_25`, `top_25_50`) to pass as   `TargetingSpec.incomeTier`, never a platform segment id. Meta's tiers are US-only   ZIP-code percentiles (label and `audienceSize` come live from Meta), TikTok expresses all   four and Google only `top_10`. `q` is matched against the label, so `top` or `income`   lists every tier - `language`: Google-only - `workPosition`, `workEmployer`, `workIndustry`: the Meta-only work demographics, whose   ids feed `TargetingSpec.workPositions`/`workEmployers`/`workIndustries` - `industry`, `jobFunction`, `seniority`, `companySize`: the LinkedIn-only B2B facets, whose   URNs feed `TargetingSpec.industries`/`jobFunctions`/`seniorities`/`companySizes`  Availability of each dimension varies by platform. A dimension a platform cannot search returns a 400 naming `dimension`; it never falls back to another dimension, and every result's `type` is the requested dimension (or the geo level for `geo`).  TikTok `interest` searches TikTok's interest category catalog (about 700 categories over four levels, `path` holds the parent categories), matched by name in Zernio. The ids are what `TargetingSpec.interests` sends to TikTok as `interest_category_ids`. Work industries are a fixed ~30-entry Meta catalog with no server-side query, so `workIndustry` matching, ranking and `limit` happen in Zernio. `language` is likewise a fixed, checked-in table of Google's targetable `language_constant` rows (id, ISO code, name) matched by name or code, capped at 20, with no network call; its ids feed `TargetingSpec.languages`.  Results are normalized across platforms into a single shape, so the same client code consumes Meta, TikTok, LinkedIn, X, Pinterest, and Google results.  TikTok geo searches return every matching level in one list (`type` is `country`, `region`, `city`, `district`, or `metro` for DMA areas), and `geoType` is not applied. Results are scoped to the advertiser's targetable markets. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is TikTok's numeric location id, usable in `regions`/`cities`/`metros` keys on `POST /v1/ads/create`.  LinkedIn geo searches also return every matching level in one list, and neither `geoType` nor `countryCode` is applied: LinkedIn's typeahead only returns a name and a URN per result, with no level or country field to filter on. A result whose URN is a country Zernio holds a code for has `type: country` and its ISO 3166-1 alpha-2 code as the id, for `targeting.countries`. Every other result has `type: region` and keeps its `urn:li:geo:*` URN as the id, usable as a `regions[].key` on `POST /v1/ads/create`, `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate` (LinkedIn puts countries and regions in the same `locations` facet, so both target the same way).  LinkedIn B2B searches (`industry`, `jobFunction`, `seniority`, `companySize`) return the full URN to pass straight back, so no URN id fragment has to be assembled by hand: `urn:li:industry:4`, `urn:li:function:8`, `urn:li:seniority:6`, `urn:li:staffCountRange:(51,200)`. Only `industry` is a server-side name search (LinkedIn's typeahead finder). LinkedIn exposes no typeahead for job functions, seniorities and company sizes, so Zernio fetches each whole table (26, 10 and 9 entries), caches it, and does the matching, ranking and `limit` cutoff itself. Those three never carry `audienceSize`, and `countryCode` and `geoType` are not applied to any of the four.  Google geo searches resolve against Google's geoTargetConstants and return every matching level in one list; `geoType` is not applied (Google's `target_type` is an open taxonomy that does not map one-to-one onto the `geoType` enum), so filter client-side on the returned `type` (`country`, `region`, `city`, `zip`, `metro`, or the lowercased Google target type for rarer levels). `countryCode` scopes the search to one country. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is Google's numeric criterion id, usable as a `regions`/`cities`/`zips`/`metros` `key` on `POST /v1/ads/create`. Google city radius is not supported (pass a `customLocations` lat/lng pin for a radius); country targeting also accepts plain ISO codes via `countries` with no search call.  Pinterest resolves against three whole-catalog endpoints (interests, locations, regions) with no server-side query or pagination, so matching, ranking and the `limit` cutoff all happen in Zernio; the catalog is independent of any ad account and results never carry `audienceSize`. Names come back localized to the connected Pinterest account's language (there is no way to force a locale), so match against whatever language that account returns.  `geoType` routes to a different Pinterest catalog:  - `country` and `metro_area` read the locations catalog (`type` is `country` or `metro`) - `region` reads the regions catalog (`type` is `region`, its id a `regions[].key` on   `POST /v1/ads/create`) - `all` and the default `city` merge both catalogs with honest per-entry `type`s, since   Pinterest has no city-level catalog and `city` is an alias for `all`, not a literal   city search - `zip`, `subcity`, `neighborhood`, `place` and `geo_market` return a 400: Pinterest   exposes no postal-code catalog, pass postal codes directly as   `targeting.zips: [{ key }]` on `POST /v1/ads/create`  For geo queries, `q` should contain only the locality name (e.g. `\"Amsterdam\"`, not `\"Amsterdam, NL\"`). Use `countryCode` to disambiguate. 
+    # Resolve a human-readable query into the platform's opaque targeting ids used in the `TargetingSpec` (`countries`/`regions`/`cities`/`zips`/`metros` geo keys, and `interests`/`behaviors` entity ids) on `POST /v1/ads/create`, `POST /v1/ads/targeting/reach-estimate`, and `saved_targeting` audiences.  The `dimension` param selects what is searched:  - `geo`: locations, further scoped by `geoType` - `interest` - `behavior`: Meta and TikTok, matched by name; ids feed `TargetingSpec.behaviors`.   Meta: its fixed behaviors catalog (e.g. `Small business owners`, `Frequent Travelers`).   TikTok: video and creator interaction categories (e.g. `Software & Apps`), with ids like   `video:1913101` or `creator:24001` and `path` starting with `Video interactions` or   `Creator interactions` - `income`: the household-income tiers the platform can target (Meta, TikTok, Google).   The id is the normalized tier (`top_5`, `top_10`, `top_10_25`, `top_25_50`) to pass as   `TargetingSpec.incomeTier`, never a platform segment id. Meta's tiers are US-only   ZIP-code percentiles (label and `audienceSize` come live from Meta), TikTok expresses all   four and Google only `top_10`. `q` is matched against the label, so `top` or `income`   lists every tier - `language`: Google-only - `workPosition`, `workEmployer`, `workIndustry`: the Meta-only work demographics, whose   ids feed `TargetingSpec.workPositions`/`workEmployers`/`workIndustries` - `industry`, `jobFunction`, `seniority`, `companySize`: the LinkedIn-only B2B facets, whose   URNs feed `TargetingSpec.industries`/`jobFunctions`/`seniorities`/`companySizes`  Availability of each dimension varies by platform. A dimension a platform cannot search returns a 400 naming `dimension`; it never falls back to another dimension, and every result's `type` is the requested dimension (or the geo level for `geo`).  TikTok `interest` searches TikTok's interest category catalog (about 700 categories over four levels, `path` holds the parent categories), matched by name in Zernio. The ids are what `TargetingSpec.interests` sends to TikTok as `interest_category_ids`. Work industries are a fixed ~30-entry Meta catalog with no server-side query, so `workIndustry` matching, ranking and `limit` happen in Zernio. `language` is likewise a fixed, checked-in table of Google's targetable `language_constant` rows (id, ISO code, name) matched by name or code, capped at 20, with no network call; its ids feed `TargetingSpec.languages`.  Results are normalized across platforms into a single shape, so the same client code consumes Meta, TikTok, LinkedIn, X, Pinterest, and Google results.  TikTok geo searches return every matching level in one list (`type` is `country`, `region`, `city`, `district`, or `metro` for DMA areas), and `geoType` is not applied. Results are scoped to the advertiser's targetable markets. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is TikTok's numeric location id, usable in `regions`/`cities`/`metros` keys on `POST /v1/ads/create`.  LinkedIn geo searches also return every matching level in one list, and neither `geoType` nor `countryCode` is applied: LinkedIn's typeahead only returns a name and a URN per result, with no level or country field to filter on. A result whose URN is a country Zernio holds a code for has `type: country` and its ISO 3166-1 alpha-2 code as the id, for `targeting.countries`. Every other result has `type: region` and keeps its `urn:li:geo:*` URN as the id, usable as a `regions[].key` on `POST /v1/ads/create`, `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate` (LinkedIn puts countries and regions in the same `locations` facet, so both target the same way).  LinkedIn B2B searches (`industry`, `jobFunction`, `seniority`, `companySize`) return the full URN to pass straight back, so no URN id fragment has to be assembled by hand: `urn:li:industry:4`, `urn:li:function:8`, `urn:li:seniority:6`, `urn:li:staffCountRange:(51,200)`. Only `industry` is a server-side name search (LinkedIn's typeahead finder). LinkedIn exposes no typeahead for job functions, seniorities and company sizes, so Zernio fetches each whole table (26, 10 and 9 entries), caches it, and does the matching, ranking and `limit` cutoff itself. Those three never carry `audienceSize`, and `countryCode` and `geoType` are not applied to any of the four.  Google geo searches resolve against Google's geoTargetConstants and return every matching level in one list; `geoType` is not applied (Google's `target_type` is an open taxonomy that does not map one-to-one onto the `geoType` enum), so filter client-side on the returned `type` (`country`, `region`, `city`, `zip`, `metro`, or the lowercased Google target type for rarer levels). `countryCode` scopes the search to one country. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is Google's numeric criterion id, usable as a `regions`/`cities`/`zips`/`metros` `key` on `POST /v1/ads/create`. Google city radius is not supported (pass a `customLocations` lat/lng pin for a radius); country targeting also accepts plain ISO codes via `countries` with no search call.  Pinterest resolves against three whole-catalog endpoints (interests, locations, regions) with no server-side query or pagination, so matching, ranking and the `limit` cutoff all happen in Zernio; the catalog is independent of any ad account and results never carry `audienceSize`. Names come back localized to the connected Pinterest account's language (there is no way to force a locale), so match against whatever language that account returns.  `geoType` routes to a different Pinterest catalog:  - `country` and `metro_area` read the locations catalog (`type` is `country` or `metro`) - `region` reads the regions catalog (`type` is `region`, its id a `regions[].key` on   `POST /v1/ads/create`) - `all` and the default `city` merge both catalogs with honest per-entry `type`s, since   Pinterest has no city-level catalog and `city` is an alias for `all`, not a literal   city search - `zip`, `subcity`, `neighborhood`, `place` and `geo_market` return a 400: Pinterest   exposes no postal-code catalog, pass postal codes directly as   `targeting.zips: [{ key }]` on `POST /v1/ads/create`  For geo queries, `q` should contain only the locality name (e.g. `\"Amsterdam\"`, not `\"Amsterdam, NL\"`). Use `countryCode` to disambiguate. 
     # @param account_id [String] Account ID (a connected account on the target ad platform).
     # @param q [String] Search query. For geo, the locality name only (no region/country suffix).
     # @param [Hash] opts the optional parameters
@@ -310,7 +310,7 @@ module Zernio
     end
 
     # Search targeting options
-    # Resolve a human-readable query into the platform's opaque targeting ids used in the `TargetingSpec` (`countries`/`regions`/`cities`/`zips`/`metros` geo keys, and `interests`/`behaviors` entity ids) on `POST /v1/ads/create`, `POST /v1/ads/targeting/reach-estimate`, and `saved_targeting` audiences.  The `dimension` param selects what is searched:  - `geo`: locations, further scoped by `geoType` - `interest` - `behavior`: Meta-only, matched by name against Meta's fixed behaviors catalog   (e.g. `Small business owners`, `Frequent Travelers`); ids feed `TargetingSpec.behaviors` - `income`: the household-income tiers the platform can target (Meta, TikTok, Google).   The id is the normalized tier (`top_5`, `top_10`, `top_10_25`, `top_25_50`) to pass as   `TargetingSpec.incomeTier`, never a platform segment id. Meta's tiers are US-only   ZIP-code percentiles (label and `audienceSize` come live from Meta), TikTok expresses all   four and Google only `top_10`. `q` is matched against the label, so `top` or `income`   lists every tier - `language`: Google-only - `workPosition`, `workEmployer`, `workIndustry`: the Meta-only work demographics, whose   ids feed `TargetingSpec.workPositions`/`workEmployers`/`workIndustries` - `industry`, `jobFunction`, `seniority`, `companySize`: the LinkedIn-only B2B facets, whose   URNs feed `TargetingSpec.industries`/`jobFunctions`/`seniorities`/`companySizes`  Availability of each dimension varies by platform. A dimension a platform cannot search returns a 400 naming `dimension`; it never falls back to another dimension, and every result's `type` is the requested dimension (or the geo level for `geo`).  TikTok `interest` searches TikTok's interest category catalog (about 700 categories over four levels, `path` holds the parent categories), matched by name in Zernio. The ids are what `TargetingSpec.interests` sends to TikTok as `interest_category_ids`. Work industries are a fixed ~30-entry Meta catalog with no server-side query, so `workIndustry` matching, ranking and `limit` happen in Zernio. `language` is likewise a fixed, checked-in table of Google's targetable `language_constant` rows (id, ISO code, name) matched by name or code, capped at 20, with no network call; its ids feed `TargetingSpec.languages`.  Results are normalized across platforms into a single shape, so the same client code consumes Meta, TikTok, LinkedIn, X, Pinterest, and Google results.  TikTok geo searches return every matching level in one list (`type` is `country`, `region`, `city`, `district`, or `metro` for DMA areas), and `geoType` is not applied. Results are scoped to the advertiser's targetable markets. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is TikTok's numeric location id, usable in `regions`/`cities`/`metros` keys on `POST /v1/ads/create`.  LinkedIn geo searches also return every matching level in one list, and neither `geoType` nor `countryCode` is applied: LinkedIn's typeahead only returns a name and a URN per result, with no level or country field to filter on. A result whose URN is a country Zernio holds a code for has `type: country` and its ISO 3166-1 alpha-2 code as the id, for `targeting.countries`. Every other result has `type: region` and keeps its `urn:li:geo:*` URN as the id, usable as a `regions[].key` on `POST /v1/ads/create`, `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate` (LinkedIn puts countries and regions in the same `locations` facet, so both target the same way).  LinkedIn B2B searches (`industry`, `jobFunction`, `seniority`, `companySize`) return the full URN to pass straight back, so no URN id fragment has to be assembled by hand: `urn:li:industry:4`, `urn:li:function:8`, `urn:li:seniority:6`, `urn:li:staffCountRange:(51,200)`. Only `industry` is a server-side name search (LinkedIn's typeahead finder). LinkedIn exposes no typeahead for job functions, seniorities and company sizes, so Zernio fetches each whole table (26, 10 and 9 entries), caches it, and does the matching, ranking and `limit` cutoff itself. Those three never carry `audienceSize`, and `countryCode` and `geoType` are not applied to any of the four.  Google geo searches resolve against Google's geoTargetConstants and return every matching level in one list; `geoType` is not applied (Google's `target_type` is an open taxonomy that does not map one-to-one onto the `geoType` enum), so filter client-side on the returned `type` (`country`, `region`, `city`, `zip`, `metro`, or the lowercased Google target type for rarer levels). `countryCode` scopes the search to one country. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is Google's numeric criterion id, usable as a `regions`/`cities`/`zips`/`metros` `key` on `POST /v1/ads/create`. Google city radius is not supported (pass a `customLocations` lat/lng pin for a radius); country targeting also accepts plain ISO codes via `countries` with no search call.  Pinterest resolves against three whole-catalog endpoints (interests, locations, regions) with no server-side query or pagination, so matching, ranking and the `limit` cutoff all happen in Zernio; the catalog is independent of any ad account and results never carry `audienceSize`. Names come back localized to the connected Pinterest account's language (there is no way to force a locale), so match against whatever language that account returns.  `geoType` routes to a different Pinterest catalog:  - `country` and `metro_area` read the locations catalog (`type` is `country` or `metro`) - `region` reads the regions catalog (`type` is `region`, its id a `regions[].key` on   `POST /v1/ads/create`) - `all` and the default `city` merge both catalogs with honest per-entry `type`s, since   Pinterest has no city-level catalog and `city` is an alias for `all`, not a literal   city search - `zip`, `subcity`, `neighborhood`, `place` and `geo_market` return a 400: Pinterest   exposes no postal-code catalog, pass postal codes directly as   `targeting.zips: [{ key }]` on `POST /v1/ads/create`  For geo queries, `q` should contain only the locality name (e.g. `\"Amsterdam\"`, not `\"Amsterdam, NL\"`). Use `countryCode` to disambiguate. 
+    # Resolve a human-readable query into the platform's opaque targeting ids used in the `TargetingSpec` (`countries`/`regions`/`cities`/`zips`/`metros` geo keys, and `interests`/`behaviors` entity ids) on `POST /v1/ads/create`, `POST /v1/ads/targeting/reach-estimate`, and `saved_targeting` audiences.  The `dimension` param selects what is searched:  - `geo`: locations, further scoped by `geoType` - `interest` - `behavior`: Meta and TikTok, matched by name; ids feed `TargetingSpec.behaviors`.   Meta: its fixed behaviors catalog (e.g. `Small business owners`, `Frequent Travelers`).   TikTok: video and creator interaction categories (e.g. `Software & Apps`), with ids like   `video:1913101` or `creator:24001` and `path` starting with `Video interactions` or   `Creator interactions` - `income`: the household-income tiers the platform can target (Meta, TikTok, Google).   The id is the normalized tier (`top_5`, `top_10`, `top_10_25`, `top_25_50`) to pass as   `TargetingSpec.incomeTier`, never a platform segment id. Meta's tiers are US-only   ZIP-code percentiles (label and `audienceSize` come live from Meta), TikTok expresses all   four and Google only `top_10`. `q` is matched against the label, so `top` or `income`   lists every tier - `language`: Google-only - `workPosition`, `workEmployer`, `workIndustry`: the Meta-only work demographics, whose   ids feed `TargetingSpec.workPositions`/`workEmployers`/`workIndustries` - `industry`, `jobFunction`, `seniority`, `companySize`: the LinkedIn-only B2B facets, whose   URNs feed `TargetingSpec.industries`/`jobFunctions`/`seniorities`/`companySizes`  Availability of each dimension varies by platform. A dimension a platform cannot search returns a 400 naming `dimension`; it never falls back to another dimension, and every result's `type` is the requested dimension (or the geo level for `geo`).  TikTok `interest` searches TikTok's interest category catalog (about 700 categories over four levels, `path` holds the parent categories), matched by name in Zernio. The ids are what `TargetingSpec.interests` sends to TikTok as `interest_category_ids`. Work industries are a fixed ~30-entry Meta catalog with no server-side query, so `workIndustry` matching, ranking and `limit` happen in Zernio. `language` is likewise a fixed, checked-in table of Google's targetable `language_constant` rows (id, ISO code, name) matched by name or code, capped at 20, with no network call; its ids feed `TargetingSpec.languages`.  Results are normalized across platforms into a single shape, so the same client code consumes Meta, TikTok, LinkedIn, X, Pinterest, and Google results.  TikTok geo searches return every matching level in one list (`type` is `country`, `region`, `city`, `district`, or `metro` for DMA areas), and `geoType` is not applied. Results are scoped to the advertiser's targetable markets. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is TikTok's numeric location id, usable in `regions`/`cities`/`metros` keys on `POST /v1/ads/create`.  LinkedIn geo searches also return every matching level in one list, and neither `geoType` nor `countryCode` is applied: LinkedIn's typeahead only returns a name and a URN per result, with no level or country field to filter on. A result whose URN is a country Zernio holds a code for has `type: country` and its ISO 3166-1 alpha-2 code as the id, for `targeting.countries`. Every other result has `type: region` and keeps its `urn:li:geo:*` URN as the id, usable as a `regions[].key` on `POST /v1/ads/create`, `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate` (LinkedIn puts countries and regions in the same `locations` facet, so both target the same way).  LinkedIn B2B searches (`industry`, `jobFunction`, `seniority`, `companySize`) return the full URN to pass straight back, so no URN id fragment has to be assembled by hand: `urn:li:industry:4`, `urn:li:function:8`, `urn:li:seniority:6`, `urn:li:staffCountRange:(51,200)`. Only `industry` is a server-side name search (LinkedIn's typeahead finder). LinkedIn exposes no typeahead for job functions, seniorities and company sizes, so Zernio fetches each whole table (26, 10 and 9 entries), caches it, and does the matching, ranking and `limit` cutoff itself. Those three never carry `audienceSize`, and `countryCode` and `geoType` are not applied to any of the four.  Google geo searches resolve against Google's geoTargetConstants and return every matching level in one list; `geoType` is not applied (Google's `target_type` is an open taxonomy that does not map one-to-one onto the `geoType` enum), so filter client-side on the returned `type` (`country`, `region`, `city`, `zip`, `metro`, or the lowercased Google target type for rarer levels). `countryCode` scopes the search to one country. A `country` result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`; every other id is Google's numeric criterion id, usable as a `regions`/`cities`/`zips`/`metros` `key` on `POST /v1/ads/create`. Google city radius is not supported (pass a `customLocations` lat/lng pin for a radius); country targeting also accepts plain ISO codes via `countries` with no search call.  Pinterest resolves against three whole-catalog endpoints (interests, locations, regions) with no server-side query or pagination, so matching, ranking and the `limit` cutoff all happen in Zernio; the catalog is independent of any ad account and results never carry `audienceSize`. Names come back localized to the connected Pinterest account's language (there is no way to force a locale), so match against whatever language that account returns.  `geoType` routes to a different Pinterest catalog:  - `country` and `metro_area` read the locations catalog (`type` is `country` or `metro`) - `region` reads the regions catalog (`type` is `region`, its id a `regions[].key` on   `POST /v1/ads/create`) - `all` and the default `city` merge both catalogs with honest per-entry `type`s, since   Pinterest has no city-level catalog and `city` is an alias for `all`, not a literal   city search - `zip`, `subcity`, `neighborhood`, `place` and `geo_market` return a 400: Pinterest   exposes no postal-code catalog, pass postal codes directly as   `targeting.zips: [{ key }]` on `POST /v1/ads/create`  For geo queries, `q` should contain only the locality name (e.g. `\"Amsterdam\"`, not `\"Amsterdam, NL\"`). Use `countryCode` to disambiguate. 
     # @param account_id [String] Account ID (a connected account on the target ad platform).
     # @param q [String] Search query. For geo, the locality name only (no region/country suffix).
     # @param [Hash] opts the optional parameters

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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0
@@ -20,7 +20,7 @@ module Zernio
       @api_client = api_client
     end
     # Create comment-to-DM automation
-    # Create a keyword-triggered DM automation on an Instagram or Facebook account. When someone comments a matching keyword (or, with `trigger: story_reply`, replies to your Instagram story with one), they automatically receive a DM.  To continue into a specific workflow after the recipient taps a button, use `{\"type\":\"postback\",\"title\":\"Send it\",\"payload\":\"zernio:workflow:<workflowId>\"}`. The target must be active and belong to the same account and profile. This also works for product-card buttons. The tap starts that workflow directly, without matching its keyword or first-message condition. A different live workflow in the conversation is exited; tapping the same live workflow does not restart it or consume a pending reply. Stale or invalid targets do nothing. The initial comment DM alone does not start the workflow: the recipient must tap.  Triggers (`trigger`):   * `comment` (default): fires on keyword comments on a post or reel.   * `story_reply`: fires when someone replies to your Instagram story with a keyword,     and answers them with a DM. Set `platformPostId` to a story media id to scope to     one story, or omit it to match replies to any story.  Targeting (comment trigger):   * Per-post: set `platformPostId` to scope to one specific post (only one active     per-post automation is allowed per post).   * Account-wide (\"any post\"): omit `platformPostId` (and `postId`). The automation     evaluates every comment on every post on the account. You can stack unlimited     account-wide automations, each with its own keyword set, and they all run     independently. Per-post automations take priority on their post.  Audience (`audience`, Instagram only): restrict the automation to followers or non-followers, and/or to accounts above a follower count. Instagram only reveals the follow relationship for people who have messaged the account, so `audience.whenUnknown` decides what happens for everyone else - including `verify`, which sends a one-tap confirmation DM (`followGate`) and then delivers the real DM automatically. People we already know follow you skip the tap entirely.  Set `alsoMatchInDms: true` on a `comment` automation to also answer people who send a keyword as a direct message instead of commenting it. One automation then covers both doors, and each door is deduplicated separately (someone who already got the DM from their comment still gets it if they later DM the keyword). Requires at least one keyword.  Links in the DM's buttons can be click-tracked (`linkTracking`, on by default) and clickers optionally tagged (`clickTag`) for segmentation. Stats returned include delivered, read, and link clicks. 
+    # Create a keyword-triggered DM automation on an Instagram or Facebook account. When someone comments a matching keyword (or, with `trigger: story_reply`, replies to your Instagram story with one), they automatically receive a DM.  To continue into a specific workflow after the recipient taps a button, use `{\"type\":\"postback\",\"title\":\"Send it\",\"payload\":\"zernio:workflow:<workflowId>\"}`. The target must be active and belong to the same account and profile. This also works for product-card buttons. The tap starts that workflow directly, without matching its keyword or first-message condition. A different live workflow in the conversation is exited; tapping the same live workflow does not restart it or consume a pending reply. Stale or invalid targets do nothing. The initial comment DM alone does not start the workflow: the recipient must tap.  Triggers (`trigger`):   * `comment` (default): fires on keyword comments on a post or reel.   * `story_reply`: fires when someone replies to your Instagram story with a keyword,     and answers them with a DM. Set `platformPostId` to a story media id to scope to     one story, or omit it to match replies to any story.  Targeting (comment trigger):   * Per-post: set `platformPostId` to scope to one specific post (only one active     per-post automation is allowed per post).   * Account-wide (\"any post\"): omit `platformPostId` (and `postId`). The automation     evaluates every comment on every post on the account. You can stack unlimited     account-wide automations, each with its own keyword set, and they all run     independently. Per-post automations take priority on their post.  Audience (`audience`, Instagram only): restrict the automation to followers or non-followers, and/or to accounts above a follower count. Instagram only reveals the follow relationship for people who have messaged the account, so `audience.whenUnknown` decides what happens for everyone else - including `verify`, which sends a one-tap confirmation DM (`followGate`) and then delivers the real DM automatically. People we already know follow you skip the tap entirely. Set `audience.tapToUnlock: true` instead to send that button DM to every commenter and deliver the real DM on the tap with no follow check.  Set `alsoMatchInDms: true` on a `comment` automation to also answer people who send a keyword as a direct message instead of commenting it. One automation then covers both doors, and each door is deduplicated separately (someone who already got the DM from their comment still gets it if they later DM the keyword). Requires at least one keyword.  Links in the DM's buttons can be click-tracked (`linkTracking`, on by default) and clickers optionally tagged (`clickTag`) for segmentation. Stats returned include delivered, read, and link clicks. 
     # @param create_comment_automation_request [CreateCommentAutomationRequest] 
     # @param [Hash] opts the optional parameters
     # @return [CreateCommentAutomation200Response]
@@ -30,7 +30,7 @@ module Zernio
     end
 
     # Create comment-to-DM automation
-    # Create a keyword-triggered DM automation on an Instagram or Facebook account. When someone comments a matching keyword (or, with &#x60;trigger: story_reply&#x60;, replies to your Instagram story with one), they automatically receive a DM.  To continue into a specific workflow after the recipient taps a button, use &#x60;{\&quot;type\&quot;:\&quot;postback\&quot;,\&quot;title\&quot;:\&quot;Send it\&quot;,\&quot;payload\&quot;:\&quot;zernio:workflow:&lt;workflowId&gt;\&quot;}&#x60;. The target must be active and belong to the same account and profile. This also works for product-card buttons. The tap starts that workflow directly, without matching its keyword or first-message condition. A different live workflow in the conversation is exited; tapping the same live workflow does not restart it or consume a pending reply. Stale or invalid targets do nothing. The initial comment DM alone does not start the workflow: the recipient must tap.  Triggers (&#x60;trigger&#x60;):   * &#x60;comment&#x60; (default): fires on keyword comments on a post or reel.   * &#x60;story_reply&#x60;: fires when someone replies to your Instagram story with a keyword,     and answers them with a DM. Set &#x60;platformPostId&#x60; to a story media id to scope to     one story, or omit it to match replies to any story.  Targeting (comment trigger):   * Per-post: set &#x60;platformPostId&#x60; to scope to one specific post (only one active     per-post automation is allowed per post).   * Account-wide (\&quot;any post\&quot;): omit &#x60;platformPostId&#x60; (and &#x60;postId&#x60;). The automation     evaluates every comment on every post on the account. You can stack unlimited     account-wide automations, each with its own keyword set, and they all run     independently. Per-post automations take priority on their post.  Audience (&#x60;audience&#x60;, Instagram only): restrict the automation to followers or non-followers, and/or to accounts above a follower count. Instagram only reveals the follow relationship for people who have messaged the account, so &#x60;audience.whenUnknown&#x60; decides what happens for everyone else - including &#x60;verify&#x60;, which sends a one-tap confirmation DM (&#x60;followGate&#x60;) and then delivers the real DM automatically. People we already know follow you skip the tap entirely.  Set &#x60;alsoMatchInDms: true&#x60; on a &#x60;comment&#x60; automation to also answer people who send a keyword as a direct message instead of commenting it. One automation then covers both doors, and each door is deduplicated separately (someone who already got the DM from their comment still gets it if they later DM the keyword). Requires at least one keyword.  Links in the DM&#39;s buttons can be click-tracked (&#x60;linkTracking&#x60;, on by default) and clickers optionally tagged (&#x60;clickTag&#x60;) for segmentation. Stats returned include delivered, read, and link clicks. 
+    # Create a keyword-triggered DM automation on an Instagram or Facebook account. When someone comments a matching keyword (or, with &#x60;trigger: story_reply&#x60;, replies to your Instagram story with one), they automatically receive a DM.  To continue into a specific workflow after the recipient taps a button, use &#x60;{\&quot;type\&quot;:\&quot;postback\&quot;,\&quot;title\&quot;:\&quot;Send it\&quot;,\&quot;payload\&quot;:\&quot;zernio:workflow:&lt;workflowId&gt;\&quot;}&#x60;. The target must be active and belong to the same account and profile. This also works for product-card buttons. The tap starts that workflow directly, without matching its keyword or first-message condition. A different live workflow in the conversation is exited; tapping the same live workflow does not restart it or consume a pending reply. Stale or invalid targets do nothing. The initial comment DM alone does not start the workflow: the recipient must tap.  Triggers (&#x60;trigger&#x60;):   * &#x60;comment&#x60; (default): fires on keyword comments on a post or reel.   * &#x60;story_reply&#x60;: fires when someone replies to your Instagram story with a keyword,     and answers them with a DM. Set &#x60;platformPostId&#x60; to a story media id to scope to     one story, or omit it to match replies to any story.  Targeting (comment trigger):   * Per-post: set &#x60;platformPostId&#x60; to scope to one specific post (only one active     per-post automation is allowed per post).   * Account-wide (\&quot;any post\&quot;): omit &#x60;platformPostId&#x60; (and &#x60;postId&#x60;). The automation     evaluates every comment on every post on the account. You can stack unlimited     account-wide automations, each with its own keyword set, and they all run     independently. Per-post automations take priority on their post.  Audience (&#x60;audience&#x60;, Instagram only): restrict the automation to followers or non-followers, and/or to accounts above a follower count. Instagram only reveals the follow relationship for people who have messaged the account, so &#x60;audience.whenUnknown&#x60; decides what happens for everyone else - including &#x60;verify&#x60;, which sends a one-tap confirmation DM (&#x60;followGate&#x60;) and then delivers the real DM automatically. People we already know follow you skip the tap entirely. Set &#x60;audience.tapToUnlock: true&#x60; instead to send that button DM to every commenter and deliver the real DM on the tap with no follow check.  Set &#x60;alsoMatchInDms: true&#x60; on a &#x60;comment&#x60; automation to also answer people who send a keyword as a direct message instead of commenting it. One automation then covers both doors, and each door is deduplicated separately (someone who already got the DM from their comment still gets it if they later DM the keyword). Requires at least one keyword.  Links in the DM&#39;s buttons can be click-tracked (&#x60;linkTracking&#x60;, on by default) and clickers optionally tagged (&#x60;clickTag&#x60;) for segmentation. Stats returned include delivered, read, and link clicks. 
     # @param create_comment_automation_request [CreateCommentAutomationRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(CreateCommentAutomation200Response, Integer, Hash)>] CreateCommentAutomation200Response data, response status code and response headers

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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/zernio-sdk/api/commerce_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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 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.177.0
+The version of the OpenAPI document: 1.179.0
 Contact: support@zernio.com
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0