late-sdk 0.0.960 → 0.0.962

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 6fa0660ea2190376f84f611b976ae8041849ea40f2a26121fbcee6f546ea157b
4
- data.tar.gz: ac84a3d7341e7e5d9f85016f5bf850bcd6fc6920308ea6d3b90bdf85c73c8f22
3
+ metadata.gz: f5bd969591c8ac97966f44e9f126322f7640ff94bbfae52edbdc1c750d953b0c
4
+ data.tar.gz: 9fc68808c6e9be10f1795b949772ffb266d3ec39cbb48e8889834e3297342aec
5
5
  SHA512:
6
- metadata.gz: cd0600c171e2cce7c39d8964c0306c60771ff11e37614854b68e8c1017f1d05a5aaabb07c1226a59d72690e9a54a44c85bab58f82c21c8c52de663007c93398d
7
- data.tar.gz: 4778504ba6a5e4251146dfb9d99d27b216af2b0f67e29a205d483890beaaa011dac4ff93b07e9f565278158b2bf73232d09a8b49963bc7d02b9968b49b6b459e
6
+ metadata.gz: 74ea1c8a7ef61ee90dc0a8260f9f0dccd7e169e524a7997c8187833e2fe4cc06f428f28ac6dca20ca767a101a52b1e1976f32069c2ea2dcf9db4ecd7b83ebbcf
7
+ data.tar.gz: 643aeb41bd3c6e8fca91ab8c89a9b1c6398b88aa0aaa33d66dce7dd0ef00e6693152d7ff04a41c986cfa9eec0e681a35bb125ef90c7f59eef4f29954652da784
@@ -295,7 +295,7 @@ end
295
295
 
296
296
  Search targeting options
297
297
 
298
- 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` - `income` - `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 (e.g. behaviours are Meta/TikTok only). 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, and every id is 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. Every result has `type` set to `location`, and its id is a `urn:li:geo:*` URN usable as a `regions[].key` on `POST /v1/ads/create`, `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate`. 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. Each 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.
298
+ 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` - `income` - `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 (e.g. behaviours are Meta/TikTok only). 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.
299
299
 
300
300
  ### Examples
301
301
 
@@ -4,7 +4,7 @@
4
4
 
5
5
  | Name | Type | Description | Notes |
6
6
  | ---- | ---- | ----------- | ----- |
7
- | **id** | **String** | The platform's opaque id. Use as a geo `key` (regions/cities/zips/metros) or an entity `id` (interests/behaviors) in TargetingSpec. | |
7
+ | **id** | **String** | The platform's opaque id. Use as a geo `key` (regions/cities/zips/metros) or an entity `id` (interests/behaviors) in TargetingSpec. A `country` result is the exception on every platform: its id is the ISO 3166-1 alpha-2 code, which is what `targeting.countries` takes. | |
8
8
  | **name** | **String** | Human-readable label. | |
9
9
  | **type** | **String** | What the result is (e.g. city, region, country, zip, metro, location, interest, behavior, income, industry, jobFunction, seniority, companySize). | |
10
10
  | **path** | **Array<String>** | Optional breadcrumb of parent labels (e.g. ['United States', 'California', 'Los Angeles']). Disambiguates same-named results. | [optional] |
@@ -8,7 +8,7 @@
8
8
  | **username** | **String** | | [optional] |
9
9
  | **name** | **String** | | [optional] |
10
10
  | **picture** | **String** | | [optional] |
11
- | **is_own_account** | **Boolean** | True when this comment was authored by the connected account itself (Meta re-delivers the account's own replies as comments events). Populated on the Instagram and Facebook realtime webhooks only; absent means not evaluated, never \"not the account\". | [optional] |
11
+ | **is_own_account** | **Boolean** | True when this comment was authored by the connected account itself. Populated on the Instagram and Facebook realtime webhooks (Meta re-delivers the account's own replies as comments events) and on TikTok, where it is inferred: comments created through this API are always flagged, and once the account's own author identifier is known (from one of those or from a comments listing) every author is compared against it. Absent means not evaluated, never \"not the account\". | [optional] |
12
12
  | **instagram_profile** | [**WebhookPayloadCommentCommentAuthorInstagramProfile**](WebhookPayloadCommentCommentAuthorInstagramProfile.md) | | [optional] |
13
13
 
14
14
  ## Example
@@ -295,7 +295,7 @@ module Zernio
295
295
  end
296
296
 
297
297
  # Search targeting options
298
- # 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` - `income` - `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 (e.g. behaviours are Meta/TikTok only). 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, and every id is 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. Every result has `type` set to `location`, and its id is a `urn:li:geo:*` URN usable as a `regions[].key` on `POST /v1/ads/create`, `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate`. 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. Each 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.
298
+ # 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` - `income` - `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 (e.g. behaviours are Meta/TikTok only). 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.
299
299
  # @param account_id [String] Account ID (a connected account on the target ad platform).
300
300
  # @param q [String] Search query. For geo, the locality name only (no region/country suffix).
301
301
  # @param [Hash] opts the optional parameters
@@ -310,7 +310,7 @@ module Zernio
310
310
  end
311
311
 
312
312
  # Search targeting options
313
- # 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` - `income` - `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 (e.g. behaviours are Meta/TikTok only). 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, and every id is 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. Every result has `type` set to `location`, and its id is a `urn:li:geo:*` URN usable as a `regions[].key` on `POST /v1/ads/create`, `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate`. 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. Each 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.
313
+ # 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` - `income` - `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 (e.g. behaviours are Meta/TikTok only). 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.
314
314
  # @param account_id [String] Account ID (a connected account on the target ad platform).
315
315
  # @param q [String] Search query. For geo, the locality name only (no region/country suffix).
316
316
  # @param [Hash] opts the optional parameters
@@ -15,7 +15,7 @@ require 'time'
15
15
 
16
16
  module Zernio
17
17
  class SearchAdTargeting200ResponseResultsInner < ApiModelBase
18
- # The platform's opaque id. Use as a geo `key` (regions/cities/zips/metros) or an entity `id` (interests/behaviors) in TargetingSpec.
18
+ # The platform's opaque id. Use as a geo `key` (regions/cities/zips/metros) or an entity `id` (interests/behaviors) in TargetingSpec. A `country` result is the exception on every platform: its id is the ISO 3166-1 alpha-2 code, which is what `targeting.countries` takes.
19
19
  attr_accessor :id
20
20
 
21
21
  # Human-readable label.
@@ -24,7 +24,7 @@ module Zernio
24
24
 
25
25
  attr_accessor :picture
26
26
 
27
- # True when this comment was authored by the connected account itself (Meta re-delivers the account's own replies as comments events). Populated on the Instagram and Facebook realtime webhooks only; absent means not evaluated, never \"not the account\".
27
+ # True when this comment was authored by the connected account itself. Populated on the Instagram and Facebook realtime webhooks (Meta re-delivers the account's own replies as comments events) and on TikTok, where it is inferred: comments created through this API are always flagged, and once the account's own author identifier is known (from one of those or from a comments listing) every author is compared against it. Absent means not evaluated, never \"not the account\".
28
28
  attr_accessor :is_own_account
29
29
 
30
30
  attr_accessor :instagram_profile
@@ -11,5 +11,5 @@ Generator version: 7.19.0
11
11
  =end
12
12
 
13
13
  module Zernio
14
- VERSION = '0.0.960'
14
+ VERSION = '0.0.962'
15
15
  end
data/openapi.yaml CHANGED
@@ -3341,7 +3341,7 @@ components:
3341
3341
  type: [string, "null"]
3342
3342
  isOwnAccount:
3343
3343
  type: boolean
3344
- description: 'True when this comment was authored by the connected account itself (Meta re-delivers the account''s own replies as comments events). Populated on the Instagram and Facebook realtime webhooks only; absent means not evaluated, never "not the account".'
3344
+ description: 'True when this comment was authored by the connected account itself. Populated on the Instagram and Facebook realtime webhooks (Meta re-delivers the account''s own replies as comments events) and on TikTok, where it is inferred: comments created through this API are always flagged, and once the account''s own author identifier is known (from one of those or from a comments listing) every author is compared against it. Absent means not evaluated, never "not the account".'
3345
3345
  instagramProfile:
3346
3346
  type: object
3347
3347
  description: |
@@ -53810,15 +53810,20 @@ paths:
53810
53810
  TikTok geo searches return every matching level in one list (`type` is
53811
53811
  `country`, `region`, `city`, `district`, or `metro` for DMA areas), and
53812
53812
  `geoType` is not applied. Results are scoped to the advertiser's targetable
53813
- markets, and every id is usable in `regions`/`cities`/`metros` keys on
53814
- `POST /v1/ads/create`.
53813
+ markets. A `country` result's id is its ISO 3166-1 alpha-2 code, for
53814
+ `targeting.countries`; every other id is TikTok's numeric location id,
53815
+ usable in `regions`/`cities`/`metros` keys on `POST /v1/ads/create`.
53815
53816
 
53816
53817
  LinkedIn geo searches also return every matching level in one list, and
53817
53818
  neither `geoType` nor `countryCode` is applied: LinkedIn's typeahead only
53818
53819
  returns a name and a URN per result, with no level or country field to
53819
- filter on. Every result has `type` set to `location`, and its id is a
53820
- `urn:li:geo:*` URN usable as a `regions[].key` on `POST /v1/ads/create`,
53821
- `POST /v1/ads/boost` and `POST /v1/ads/targeting/reach-estimate`.
53820
+ filter on. A result whose URN is a country Zernio holds a code for has
53821
+ `type: country` and its ISO 3166-1 alpha-2 code as the id, for
53822
+ `targeting.countries`. Every other result has `type: region` and keeps
53823
+ its `urn:li:geo:*` URN as the id, usable as a `regions[].key` on
53824
+ `POST /v1/ads/create`, `POST /v1/ads/boost` and
53825
+ `POST /v1/ads/targeting/reach-estimate` (LinkedIn puts countries and
53826
+ regions in the same `locations` facet, so both target the same way).
53822
53827
 
53823
53828
  LinkedIn B2B searches (`industry`, `jobFunction`, `seniority`, `companySize`) return the
53824
53829
  full URN to pass straight back, so no URN id fragment has to be assembled by hand:
@@ -53834,11 +53839,13 @@ paths:
53834
53839
  `target_type` is an open taxonomy that does not map one-to-one onto the
53835
53840
  `geoType` enum), so filter client-side on the returned `type` (`country`,
53836
53841
  `region`, `city`, `zip`, `metro`, or the lowercased Google target type for
53837
- rarer levels). `countryCode` scopes the search to one country. Each id is
53838
- Google's numeric criterion id, usable as a `regions`/`cities`/`zips`/`metros`
53839
- `key` on `POST /v1/ads/create`. Google city radius is not supported (pass a
53840
- `customLocations` lat/lng pin for a radius); country targeting also accepts
53841
- plain ISO codes via `countries` with no search call.
53842
+ rarer levels). `countryCode` scopes the search to one country. A `country`
53843
+ result's id is its ISO 3166-1 alpha-2 code, for `targeting.countries`;
53844
+ every other id is Google's numeric criterion id, usable as a
53845
+ `regions`/`cities`/`zips`/`metros` `key` on `POST /v1/ads/create`. Google
53846
+ city radius is not supported (pass a `customLocations` lat/lng pin for a
53847
+ radius); country targeting also accepts plain ISO codes via `countries`
53848
+ with no search call.
53842
53849
 
53843
53850
  Pinterest resolves against three whole-catalog endpoints (interests, locations,
53844
53851
  regions) with no server-side query or pagination, so matching, ranking and the
@@ -53885,7 +53892,7 @@ paths:
53885
53892
  type: object
53886
53893
  required: [id, name, type]
53887
53894
  properties:
53888
- id: { type: string, description: "The platform's opaque id. Use as a geo `key` (regions/cities/zips/metros) or an entity `id` (interests/behaviors) in TargetingSpec." }
53895
+ id: { type: string, description: "The platform's opaque id. Use as a geo `key` (regions/cities/zips/metros) or an entity `id` (interests/behaviors) in TargetingSpec. A `country` result is the exception on every platform: its id is the ISO 3166-1 alpha-2 code, which is what `targeting.countries` takes." }
53889
53896
  name: { type: string, description: "Human-readable label." }
53890
53897
  type: { type: string, description: "What the result is (e.g. city, region, country, zip, metro, location, interest, behavior, income, industry, jobFunction, seniority, companySize)." }
53891
53898
  path: { type: array, items: { type: string }, description: "Optional breadcrumb of parent labels (e.g. ['United States', 'California', 'Los Angeles']). Disambiguates same-named results." }
@@ -83,7 +83,7 @@ describe 'AdTargetingApi' do
83
83
 
84
84
  # unit tests for search_ad_targeting
85
85
  # Search targeting options
86
- # Resolve a human-readable query into the platform&#39;s opaque targeting ids used in the &#x60;TargetingSpec&#x60; (&#x60;countries&#x60;/&#x60;regions&#x60;/&#x60;cities&#x60;/&#x60;zips&#x60;/&#x60;metros&#x60; geo keys, and &#x60;interests&#x60;/&#x60;behaviors&#x60; entity ids) on &#x60;POST /v1/ads/create&#x60;, &#x60;POST /v1/ads/targeting/reach-estimate&#x60;, and &#x60;saved_targeting&#x60; audiences. The &#x60;dimension&#x60; param selects what is searched: - &#x60;geo&#x60;: locations, further scoped by &#x60;geoType&#x60; - &#x60;interest&#x60; - &#x60;behavior&#x60; - &#x60;income&#x60; - &#x60;language&#x60;: Google-only - &#x60;workPosition&#x60;, &#x60;workEmployer&#x60;, &#x60;workIndustry&#x60;: the Meta-only work demographics, whose ids feed &#x60;TargetingSpec.workPositions&#x60;/&#x60;workEmployers&#x60;/&#x60;workIndustries&#x60; - &#x60;industry&#x60;, &#x60;jobFunction&#x60;, &#x60;seniority&#x60;, &#x60;companySize&#x60;: the LinkedIn-only B2B facets, whose URNs feed &#x60;TargetingSpec.industries&#x60;/&#x60;jobFunctions&#x60;/&#x60;seniorities&#x60;/&#x60;companySizes&#x60; Availability of each dimension varies by platform (e.g. behaviours are Meta/TikTok only). Work industries are a fixed ~30-entry Meta catalog with no server-side query, so &#x60;workIndustry&#x60; matching, ranking and &#x60;limit&#x60; happen in Zernio. &#x60;language&#x60; is likewise a fixed, checked-in table of Google&#39;s targetable &#x60;language_constant&#x60; rows (id, ISO code, name) matched by name or code, capped at 20, with no network call; its ids feed &#x60;TargetingSpec.languages&#x60;. 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 (&#x60;type&#x60; is &#x60;country&#x60;, &#x60;region&#x60;, &#x60;city&#x60;, &#x60;district&#x60;, or &#x60;metro&#x60; for DMA areas), and &#x60;geoType&#x60; is not applied. Results are scoped to the advertiser&#39;s targetable markets, and every id is usable in &#x60;regions&#x60;/&#x60;cities&#x60;/&#x60;metros&#x60; keys on &#x60;POST /v1/ads/create&#x60;. LinkedIn geo searches also return every matching level in one list, and neither &#x60;geoType&#x60; nor &#x60;countryCode&#x60; is applied: LinkedIn&#39;s typeahead only returns a name and a URN per result, with no level or country field to filter on. Every result has &#x60;type&#x60; set to &#x60;location&#x60;, and its id is a &#x60;urn:li:geo:*&#x60; URN usable as a &#x60;regions[].key&#x60; on &#x60;POST /v1/ads/create&#x60;, &#x60;POST /v1/ads/boost&#x60; and &#x60;POST /v1/ads/targeting/reach-estimate&#x60;. LinkedIn B2B searches (&#x60;industry&#x60;, &#x60;jobFunction&#x60;, &#x60;seniority&#x60;, &#x60;companySize&#x60;) return the full URN to pass straight back, so no URN id fragment has to be assembled by hand: &#x60;urn:li:industry:4&#x60;, &#x60;urn:li:function:8&#x60;, &#x60;urn:li:seniority:6&#x60;, &#x60;urn:li:staffCountRange:(51,200)&#x60;. Only &#x60;industry&#x60; is a server-side name search (LinkedIn&#39;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 &#x60;limit&#x60; cutoff itself. Those three never carry &#x60;audienceSize&#x60;, and &#x60;countryCode&#x60; and &#x60;geoType&#x60; are not applied to any of the four. Google geo searches resolve against Google&#39;s geoTargetConstants and return every matching level in one list; &#x60;geoType&#x60; is not applied (Google&#39;s &#x60;target_type&#x60; is an open taxonomy that does not map one-to-one onto the &#x60;geoType&#x60; enum), so filter client-side on the returned &#x60;type&#x60; (&#x60;country&#x60;, &#x60;region&#x60;, &#x60;city&#x60;, &#x60;zip&#x60;, &#x60;metro&#x60;, or the lowercased Google target type for rarer levels). &#x60;countryCode&#x60; scopes the search to one country. Each id is Google&#39;s numeric criterion id, usable as a &#x60;regions&#x60;/&#x60;cities&#x60;/&#x60;zips&#x60;/&#x60;metros&#x60; &#x60;key&#x60; on &#x60;POST /v1/ads/create&#x60;. Google city radius is not supported (pass a &#x60;customLocations&#x60; lat/lng pin for a radius); country targeting also accepts plain ISO codes via &#x60;countries&#x60; 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 &#x60;limit&#x60; cutoff all happen in Zernio; the catalog is independent of any ad account and results never carry &#x60;audienceSize&#x60;. Names come back localized to the connected Pinterest account&#39;s language (there is no way to force a locale), so match against whatever language that account returns. &#x60;geoType&#x60; routes to a different Pinterest catalog: - &#x60;country&#x60; and &#x60;metro_area&#x60; read the locations catalog (&#x60;type&#x60; is &#x60;country&#x60; or &#x60;metro&#x60;) - &#x60;region&#x60; reads the regions catalog (&#x60;type&#x60; is &#x60;region&#x60;, its id a &#x60;regions[].key&#x60; on &#x60;POST /v1/ads/create&#x60;) - &#x60;all&#x60; and the default &#x60;city&#x60; merge both catalogs with honest per-entry &#x60;type&#x60;s, since Pinterest has no city-level catalog and &#x60;city&#x60; is an alias for &#x60;all&#x60;, not a literal city search - &#x60;zip&#x60;, &#x60;subcity&#x60;, &#x60;neighborhood&#x60;, &#x60;place&#x60; and &#x60;geo_market&#x60; return a 400: Pinterest exposes no postal-code catalog, pass postal codes directly as &#x60;targeting.zips: [{ key }]&#x60; on &#x60;POST /v1/ads/create&#x60; For geo queries, &#x60;q&#x60; should contain only the locality name (e.g. &#x60;\&quot;Amsterdam\&quot;&#x60;, not &#x60;\&quot;Amsterdam, NL\&quot;&#x60;). Use &#x60;countryCode&#x60; to disambiguate.
86
+ # Resolve a human-readable query into the platform&#39;s opaque targeting ids used in the &#x60;TargetingSpec&#x60; (&#x60;countries&#x60;/&#x60;regions&#x60;/&#x60;cities&#x60;/&#x60;zips&#x60;/&#x60;metros&#x60; geo keys, and &#x60;interests&#x60;/&#x60;behaviors&#x60; entity ids) on &#x60;POST /v1/ads/create&#x60;, &#x60;POST /v1/ads/targeting/reach-estimate&#x60;, and &#x60;saved_targeting&#x60; audiences. The &#x60;dimension&#x60; param selects what is searched: - &#x60;geo&#x60;: locations, further scoped by &#x60;geoType&#x60; - &#x60;interest&#x60; - &#x60;behavior&#x60; - &#x60;income&#x60; - &#x60;language&#x60;: Google-only - &#x60;workPosition&#x60;, &#x60;workEmployer&#x60;, &#x60;workIndustry&#x60;: the Meta-only work demographics, whose ids feed &#x60;TargetingSpec.workPositions&#x60;/&#x60;workEmployers&#x60;/&#x60;workIndustries&#x60; - &#x60;industry&#x60;, &#x60;jobFunction&#x60;, &#x60;seniority&#x60;, &#x60;companySize&#x60;: the LinkedIn-only B2B facets, whose URNs feed &#x60;TargetingSpec.industries&#x60;/&#x60;jobFunctions&#x60;/&#x60;seniorities&#x60;/&#x60;companySizes&#x60; Availability of each dimension varies by platform (e.g. behaviours are Meta/TikTok only). Work industries are a fixed ~30-entry Meta catalog with no server-side query, so &#x60;workIndustry&#x60; matching, ranking and &#x60;limit&#x60; happen in Zernio. &#x60;language&#x60; is likewise a fixed, checked-in table of Google&#39;s targetable &#x60;language_constant&#x60; rows (id, ISO code, name) matched by name or code, capped at 20, with no network call; its ids feed &#x60;TargetingSpec.languages&#x60;. 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 (&#x60;type&#x60; is &#x60;country&#x60;, &#x60;region&#x60;, &#x60;city&#x60;, &#x60;district&#x60;, or &#x60;metro&#x60; for DMA areas), and &#x60;geoType&#x60; is not applied. Results are scoped to the advertiser&#39;s targetable markets. A &#x60;country&#x60; result&#39;s id is its ISO 3166-1 alpha-2 code, for &#x60;targeting.countries&#x60;; every other id is TikTok&#39;s numeric location id, usable in &#x60;regions&#x60;/&#x60;cities&#x60;/&#x60;metros&#x60; keys on &#x60;POST /v1/ads/create&#x60;. LinkedIn geo searches also return every matching level in one list, and neither &#x60;geoType&#x60; nor &#x60;countryCode&#x60; is applied: LinkedIn&#39;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 &#x60;type: country&#x60; and its ISO 3166-1 alpha-2 code as the id, for &#x60;targeting.countries&#x60;. Every other result has &#x60;type: region&#x60; and keeps its &#x60;urn:li:geo:*&#x60; URN as the id, usable as a &#x60;regions[].key&#x60; on &#x60;POST /v1/ads/create&#x60;, &#x60;POST /v1/ads/boost&#x60; and &#x60;POST /v1/ads/targeting/reach-estimate&#x60; (LinkedIn puts countries and regions in the same &#x60;locations&#x60; facet, so both target the same way). LinkedIn B2B searches (&#x60;industry&#x60;, &#x60;jobFunction&#x60;, &#x60;seniority&#x60;, &#x60;companySize&#x60;) return the full URN to pass straight back, so no URN id fragment has to be assembled by hand: &#x60;urn:li:industry:4&#x60;, &#x60;urn:li:function:8&#x60;, &#x60;urn:li:seniority:6&#x60;, &#x60;urn:li:staffCountRange:(51,200)&#x60;. Only &#x60;industry&#x60; is a server-side name search (LinkedIn&#39;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 &#x60;limit&#x60; cutoff itself. Those three never carry &#x60;audienceSize&#x60;, and &#x60;countryCode&#x60; and &#x60;geoType&#x60; are not applied to any of the four. Google geo searches resolve against Google&#39;s geoTargetConstants and return every matching level in one list; &#x60;geoType&#x60; is not applied (Google&#39;s &#x60;target_type&#x60; is an open taxonomy that does not map one-to-one onto the &#x60;geoType&#x60; enum), so filter client-side on the returned &#x60;type&#x60; (&#x60;country&#x60;, &#x60;region&#x60;, &#x60;city&#x60;, &#x60;zip&#x60;, &#x60;metro&#x60;, or the lowercased Google target type for rarer levels). &#x60;countryCode&#x60; scopes the search to one country. A &#x60;country&#x60; result&#39;s id is its ISO 3166-1 alpha-2 code, for &#x60;targeting.countries&#x60;; every other id is Google&#39;s numeric criterion id, usable as a &#x60;regions&#x60;/&#x60;cities&#x60;/&#x60;zips&#x60;/&#x60;metros&#x60; &#x60;key&#x60; on &#x60;POST /v1/ads/create&#x60;. Google city radius is not supported (pass a &#x60;customLocations&#x60; lat/lng pin for a radius); country targeting also accepts plain ISO codes via &#x60;countries&#x60; 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 &#x60;limit&#x60; cutoff all happen in Zernio; the catalog is independent of any ad account and results never carry &#x60;audienceSize&#x60;. Names come back localized to the connected Pinterest account&#39;s language (there is no way to force a locale), so match against whatever language that account returns. &#x60;geoType&#x60; routes to a different Pinterest catalog: - &#x60;country&#x60; and &#x60;metro_area&#x60; read the locations catalog (&#x60;type&#x60; is &#x60;country&#x60; or &#x60;metro&#x60;) - &#x60;region&#x60; reads the regions catalog (&#x60;type&#x60; is &#x60;region&#x60;, its id a &#x60;regions[].key&#x60; on &#x60;POST /v1/ads/create&#x60;) - &#x60;all&#x60; and the default &#x60;city&#x60; merge both catalogs with honest per-entry &#x60;type&#x60;s, since Pinterest has no city-level catalog and &#x60;city&#x60; is an alias for &#x60;all&#x60;, not a literal city search - &#x60;zip&#x60;, &#x60;subcity&#x60;, &#x60;neighborhood&#x60;, &#x60;place&#x60; and &#x60;geo_market&#x60; return a 400: Pinterest exposes no postal-code catalog, pass postal codes directly as &#x60;targeting.zips: [{ key }]&#x60; on &#x60;POST /v1/ads/create&#x60; For geo queries, &#x60;q&#x60; should contain only the locality name (e.g. &#x60;\&quot;Amsterdam\&quot;&#x60;, not &#x60;\&quot;Amsterdam, NL\&quot;&#x60;). Use &#x60;countryCode&#x60; to disambiguate.
87
87
  # @param account_id Account ID (a connected account on the target ad platform).
88
88
  # @param q Search query. For geo, the locality name only (no region/country suffix).
89
89
  # @param [Hash] opts the optional parameters
Binary file
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: late-sdk
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.0.960
4
+ version: 0.0.962
5
5
  platform: ruby
6
6
  authors:
7
7
  - OpenAPI-Generator
@@ -6487,7 +6487,7 @@ files:
6487
6487
  - spec/models/you_tube_video_retention_response_retention_curve_inner_spec.rb
6488
6488
  - spec/models/you_tube_video_retention_response_spec.rb
6489
6489
  - spec/spec_helper.rb
6490
- - zernio-sdk-0.0.960.gem
6490
+ - zernio-sdk-0.0.962.gem
6491
6491
  - zernio-sdk.gemspec
6492
6492
  homepage: https://openapi-generator.tech
6493
6493
  licenses:
Binary file