late-sdk 0.0.716 → 0.0.718

data/spec/api/accounts_api_spec.rb

@@ -46,7 +46,7 @@ describe 'AccountsApi' do
 
   # unit tests for get_account_health
   # Check account health
-  # Returns detailed health info for a specific account including token status, permissions, and recommendations.
+  # Returns detailed health info for a specific account including token status, permissions, and recommendations.  For WhatsApp accounts the response also includes `platformConnection`, a live probe of the Meta link behind the channel (the same read as `GET /v1/whatsapp/number-info`). The OAuth token can be perfectly valid while Meta refuses to serve the phone-number object (for example after a phone-side coexistence disconnect), so `tokenStatus` alone is not a liveness signal for WhatsApp. When the Meta link is dead, `platformConnection.status` is `disconnected` and the overall `status` is `error`. 
   # @param account_id The account ID to check
   # @param [Hash] opts the optional parameters
   # @return [GetAccountHealth200Response]
@@ -70,6 +70,18 @@ describe 'AccountsApi' do
     end
   end
 
+  # unit tests for get_bluesky_settings
+  # Get Bluesky account settings
+  # Returns the account's default post languages (defaultLangs), applied at publish time whenever a post's platformSpecificData.langs is absent. Null when no default is set.
+  # @param account_id 
+  # @param [Hash] opts the optional parameters
+  # @return [GetBlueskySettings200Response]
+  describe 'get_bluesky_settings test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
   # unit tests for get_follower_stats
   # Get follower stats
   # Returns follower count history and growth metrics for connected social accounts. Requires analytics add-on subscription. Follower counts are refreshed once per day. 
@@ -168,6 +180,19 @@ describe 'AccountsApi' do
     end
   end
 
+  # unit tests for update_bluesky_settings
+  # Update Bluesky account settings
+  # Set or clear the account's default post languages. 1-3 BCP-47 codes (e.g. \"pt\", \"en-US\"), the same validation as per-post langs; explicit null clears the default. Per-post platformSpecificData.langs always overrides this default. Applies to posts published after the change; already-published posts cannot be retagged (Bluesky has no post edit).
+  # @param account_id 
+  # @param update_bluesky_settings_request 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'update_bluesky_settings test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
   # unit tests for update_slack_settings
   # Update Slack account settings
   # Set or clear the default message identity for this channel. Empty string clears a field; per-post platformSpecificData.username/iconUrl still override these defaults.

data/spec/api/ad_campaigns_api_spec.rb

@@ -34,9 +34,10 @@ describe 'AdCampaignsApi' do
 
   # unit tests for boost_post
   # Boost post as ad
-  # Creates a paid ad from an existing published post, keeping the post's engagement. By default it provisions the whole hierarchy (campaign, ad set, ad).  **Attach shape (Meta).** Send `adSetId` to put the ad under an EXISTING ad set instead, so that ad set keeps its learning phase. It then owns `budget`, `schedule` and `targeting`, and sending any of those alongside `adSetId` is a 400 rather than a silent drop. `budget` is required only without `adSetId`.  `instagramAccountId`, `destinationType` and `adSetId` are Meta-only and return 400 on other platforms. 
+  # Creates a paid ad from an existing published post, keeping the post's engagement. By default it provisions the whole hierarchy (campaign, ad set, ad).  **Attach shape (Meta).** Send `adSetId` to put the ad under an EXISTING ad set instead, so that ad set keeps its learning phase. It then owns `budget`, `schedule` and `targeting`, and sending any of those alongside `adSetId` is a 400 rather than a silent drop. `budget` is required only without `adSetId`.  `instagramAccountId`, `destinationType` and `adSetId` are Meta-only and return 400 on other platforms.  **Retries.** Boosts are NOT idempotent and can take minutes when Meta requires re-hosting an Instagram video, so do not retry on client timeout. Send an Idempotency-Key header to make retries safe: same key and body replays the original 201, and distinct keys always create distinct ads. Without the header, an identical request is treated as a retry: while one is in flight it returns 409, and within 10 minutes of a completed boost it returns the already-created ad instead of creating another. To intentionally duplicate an ad, send distinct Idempotency-Keys (or vary the body, e.g. the name). 
   # @param boost_post_request 
   # @param [Hash] opts the optional parameters
+  # @option opts [String] :idempotency_key Optional client-generated unique key (e.g. a UUID) that makes retries safe. Same key + same body replays the original response; same key + different body → 422; key still processing → 409.
   # @return [UpdateAd200Response]
   describe 'boost_post test' do
     it 'should work' do
@@ -189,8 +190,10 @@ describe 'AdCampaignsApi' do
   # @option opts [String] :account_id Social account ID
   # @option opts [String] :profile_id Profile ID
   # @option opts [String] :campaign_id Restrict the tree to a single campaign by its platform campaign id (the id the platform assigns, e.g. Meta's numeric campaign id). Filters the campaign set itself, so it works regardless of account size and pagination — pass this when you already hold a campaign id instead of paging the tree to find it. Mirrors the `campaignId` filter on GET /v1/ads.
-  # @option opts [Date] :from_date Start of the METRICS date range (YYYY-MM-DD). Affects only the spend/impression numbers overlaid on each node, NOT which campaigns are returned. Defaults to 90 days ago.
+  # @option opts [Date] :from_date Start of the METRICS date range (YYYY-MM-DD). On its own it affects only the spend/impression numbers overlaid on each node, not which campaigns are returned — pass `hasDelivery` or `minSpend` to also filter the campaign set to this window. Defaults to 90 days ago.
   # @option opts [Date] :to_date End of metrics date range (YYYY-MM-DD). Defaults to today. Max 730-day range.
+  # @option opts [Boolean] :has_delivery Return only campaigns that delivered between `fromDate` and `toDate` — spend above zero, or impressions served at zero spend. Unlike `status`, which reads a campaign's CURRENT state, this filters on what happened inside the window, so a campaign that spent then and is paused today is still returned. Filters the campaign set itself, so `pagination.total` counts only matching campaigns.
+  # @option opts [Float] :min_spend Return only campaigns whose spend between `fromDate` and `toDate` reaches this amount. Expressed in each campaign's OWN currency (the `currency` field on the campaign node): spend is stored per ad account in its native currency and one response can span several. Implies `hasDelivery`; `minSpend=0` applies no filter.
   # @option opts [String] :sort Campaign-level sort order. `newest` (default) / `oldest` order by the campaign's newest-ad createdAt. `spend_desc` / `spend_asc` order by aggregated spend in the requested date range; campaigns with no spend land at the end.
   # @option opts [Integer] :time_increment Set to `1` to also return a daily breakdown. Mirrors Meta Insights' `time_increment=1`: each node gains a `daily[]` array of per-day metrics (same fields as the aggregated `metrics`) alongside the range total, so you get per-entity daily trends in ONE call instead of calling the tree once per day. Only `1` (daily) is supported. The daily series covers the same date range and uses the same source data as `metrics`, except `reach` on Meta and TikTok: the range total is the platform's de-duplicated value, so daily reach does not sum to it. See `dailyLevel` to control which levels carry it.
   # @option opts [String] :daily_level Which tree levels get the `daily[]` series when `timeIncrement=1`. `campaign` (default) attaches it on campaign nodes only — the common per-campaign-trend case, and the smallest payload. `adset` adds it on ad sets too; `ad` adds it on every ad in `ads[]` as well (heaviest — a long range × up to 100 ads per ad set). Scope with `campaignId` to keep `ad`-level responses small. Ignored when `timeIncrement` is unset.
@@ -233,6 +236,8 @@ describe 'AdCampaignsApi' do
   # @option opts [String] :profile_id Profile ID
   # @option opts [Date] :from_date Start of metrics date range (YYYY-MM-DD, inclusive). Defaults to 90 days ago when both date params are omitted.
   # @option opts [Date] :to_date End of metrics date range (YYYY-MM-DD, inclusive). Defaults to today. Max 730-day range.
+  # @option opts [Boolean] :has_delivery Return only campaigns that delivered between `fromDate` and `toDate` — spend above zero, or impressions served at zero spend. Unlike `status`, which reads a campaign's CURRENT state, this filters on what happened inside the window. Filters the campaign set itself, so `pagination.total` counts only matching campaigns. Mirrors the same filter on /v1/ads/tree.
+  # @option opts [Float] :min_spend Return only campaigns whose spend between `fromDate` and `toDate` reaches this amount, in each campaign's OWN currency (the `currency` field on the campaign). Implies `hasDelivery`; `minSpend=0` applies no filter. Mirrors the same filter on /v1/ads/tree.
   # @return [ListAdCampaigns200Response]
   describe 'list_ad_campaigns test' do
     it 'should work' do
@@ -316,7 +321,7 @@ describe 'AdCampaignsApi' do
 
   # unit tests for update_ad_campaign_status
   # Pause or resume a campaign
-  # Updates the status of all ads in a campaign. Makes one platform API call (not per-ad) since status cascades through the campaign hierarchy. Ads in terminal statuses (rejected, completed, cancelled) are automatically skipped. 
+  # Writes the campaign's own on/off switch, then lets the platform cascade delivery to its ad sets and ads. Makes one platform API call, not one per ad.  The switch is always written, whatever delivery status the ads underneath report: an ad still in review does not block resuming its campaign. The echoed `status` is the confirmation that it landed.  `updated` / `skipped` describe only the ads whose own stored status CHANGED alongside it, so `updated: 0` is a normal successful response, not a no-op. Ads are skipped when they are in a terminal status (rejected, completed, cancelled), already in the target state, or switched on but not yet delivering — the last group keeps its `pending_review` / `error` status until the platform reports what it became. `skippedReasons` names which case applies.  On Meta this flips the campaign only. An ad set paused in its own right stays paused, so pair this with PUT /v1/ads/ad-sets/{adSetId}/status when you also need the ad set switched back on. 
   # @param campaign_id Platform campaign ID
   # @param update_ad_campaign_status_request 
   # @param [Hash] opts the optional parameters
@@ -342,7 +347,7 @@ describe 'AdCampaignsApi' do
 
   # unit tests for update_ad_set_status
   # Pause or resume a single ad set
-  # Ad-set-scoped pause/resume (doesn't touch sibling ad sets). Thin wrapper over PUT /v1/ads/ad-sets/{adSetId} for callers that only want the status toggle and prefer a symmetric URL to /v1/ads/campaigns/{campaignId}/status. 
+  # Ad-set-scoped pause/resume (doesn't touch sibling ad sets). Thin wrapper over PUT /v1/ads/ad-sets/{adSetId} for callers that only want the status toggle and prefer a symmetric URL to /v1/ads/campaigns/{campaignId}/status.  On Meta and LinkedIn this writes the ad set's own on/off switch (Meta: `configured_status`), whatever delivery status its ads report — an ad still in review does not block resuming its ad set. The echoed `status` is the confirmation that it landed. Where the platform has no ad-set switch (TikTok and others) the toggle is emulated by flipping the child ads; a call with no actionable ad then writes nothing and returns a `message` with no `status`.  `updated` / `skipped` describe only the ads whose own stored status CHANGED alongside the switch, so `updated: 0` is a normal successful response. See `skippedReasons` for which of the three cases applies (terminal, already in the target state, or switched on but not yet delivering).  A campaign created paused needs its campaign resumed as well: pair this with PUT /v1/ads/campaigns/{campaignId}/status. 
   # @param ad_set_id Platform ad set ID
   # @param update_ad_campaign_status_request 
   # @param [Hash] opts the optional parameters

data/spec/api/ad_insights_api_spec.rb

@@ -132,6 +132,40 @@ describe 'AdInsightsApi' do
     end
   end
 
+  # unit tests for list_local_services_lead_conversations
+  # Conversations of a Local Services lead
+  # Conversation entries of one Local Services lead: phone calls (duration, recording URL) and messages (text, attachment URLs), oldest first. Read live from `local_services_lead_conversation`, always scoped to a single lead. Call-recording URLs require read access on the Google Ads account. Draws on the shared Google Ads operations budget.
+  # @param lead_id Numeric lead id from /v1/ads/local-services/leads.
+  # @param account_id Google ads SocialAccount id.
+  # @param [Hash] opts the optional parameters
+  # @option opts [String] :customer_id Numeric Google Ads customer id (no dashes). Defaults to the account's connected customer.
+  # @option opts [String] :page_token Cursor from paging.nextPageToken of the previous page.
+  # @return [ListLocalServicesLeadConversations200Response]
+  describe 'list_local_services_lead_conversations test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for list_local_services_leads
+  # Google Local Services Ads leads
+  # Leads generated by Local Services Ads (phone calls, messages, bookings), read live from Google's `local_services_lead` resource, newest first. No persistence: Google is the source of truth and lead/credit statuses keep changing server-side. Google never returns healthcare-category leads, and `WIPED_OUT` leads arrive with contact erased (`contact` is null). Draws on the shared Google Ads operations budget.
+  # @param account_id Google ads SocialAccount id.
+  # @param [Hash] opts the optional parameters
+  # @option opts [String] :customer_id Numeric Google Ads customer id (no dashes). Defaults to the account's connected customer.
+  # @option opts [Date] :from_date Leads created at/after this day.
+  # @option opts [Date] :to_date Leads created at/before this day.
+  # @option opts [String] :lead_type 
+  # @option opts [String] :lead_status Google LocalServicesLeadStatus enum value (e.g. NEW, BOOKED, WIPED_OUT).
+  # @option opts [Boolean] :charged_only true = only leads Google charged for.
+  # @option opts [String] :page_token Cursor from paging.nextPageToken of the previous page.
+  # @return [ListLocalServicesLeads200Response]
+  describe 'list_local_services_leads test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
   # unit tests for query_ad_insights
   # Flexible live insights query
   # Live, flexible insights query. The account's platform picks the contract:  **Meta (facebook/instagram)**: forwards caller-chosen `fields`, `breakdowns` and `filtering` to any Meta insights node and returns Meta's rows verbatim. `objectId` (required) selects the node; `level` sets row granularity. Semantic validation is Meta's: an unknown field or invalid breakdown combination returns a 400 carrying Meta's message. For long ranges or agency-scale accounts prefer the async variant (POST /v1/ads/insights/reports).  **Google Ads (googleads)**: raw GAQL passthrough. Send any read-only GAQL SELECT via `query` (campaign/keyword/search-term/geo/demographic/asset/shopping resources, `change_event`, any `segments.*`) and rows come back verbatim (camelCase, counters as strings). Results are paged at a fixed 10,000 rows; follow `paging.nextPageToken` with `pageToken`. `customerId` is only needed when the connection has several Google Ads accounts. Semantic validation is Google's: an invalid query returns a 400 carrying Google's message (note: selecting `segments.date` requires a finite date filter). 

data/spec/api/ad_targeting_api_spec.rb

@@ -83,12 +83,12 @@ describe 'AdTargetingApi' do
 
   # unit tests for search_ad_targeting
   # 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`, or `income`. Availability of each dimension varies by platform (e.g. behaviours are Meta/TikTok only). 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) — `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`.  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`, or `income`. Availability of each dimension varies by platform (e.g. behaviours are Meta/TikTok only). 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) — `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`.  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 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 Social account ID (a connected account on the target ad platform).
   # @param q Search query. For geo, the locality name only (no region/country suffix).
   # @param [Hash] opts the optional parameters
   # @option opts [String] :dimension What to search. `geo` resolves locations (scope further with `geoType`), `interest`/`behavior` resolve audience entities, `income` resolves income-tier options. Defaults to `interest` for backward compatibility with the deprecated /v1/ads/interests alias.
-  # @option opts [String] :geo_type Only used when `dimension=geo`. The kind of location to resolve. Defaults to `city`.
+  # @option opts [String] :geo_type Only used when `dimension=geo`. The kind of location to resolve. `all` searches every type in one relevance-ranked call. Defaults to `city`.
   # @option opts [String] :country_code ISO 3166-1 alpha-2 country code (e.g. NL) to scope a geo search.
   # @option opts [Integer] :limit Maximum results to return.
   # @return [SearchAdTargeting200Response]

data/spec/api/blogs_api_spec.rb

@@ -0,0 +1,174 @@
+=begin
+#Zernio API
+
+#API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api 
+
+The version of the OpenAPI document: 1.0.4
+Contact: support@zernio.com
+Generated by: https://openapi-generator.tech
+Generator version: 7.19.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for Zernio::BlogsApi
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'BlogsApi' do
+  before do
+    # run before each test
+    @api_instance = Zernio::BlogsApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of BlogsApi' do
+    it 'should create an instance of BlogsApi' do
+      expect(@api_instance).to be_instance_of(Zernio::BlogsApi)
+    end
+  end
+
+  # unit tests for create_blog
+  # Create a blog
+  # Creates a blog on the connected store. The platform generates the URL `handle` from the title when omitted.  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param create_blog_request 
+  # @param [Hash] opts the optional parameters
+  # @return [CreateBlog201Response]
+  describe 'create_blog test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for create_blog_article
+  # Create a blog article
+  # Creates an article on the blog. Publishing behavior:  - `isPublished: false` keeps the article as a draft. - A future `publishDate` schedules publication natively on the   platform; the platform publishes it at that time with no Zernio   queue involved. - `seo.title` / `seo.description` map to Shopify's global `title_tag`   and `description_tag` metafields (the fields Shopify themes read for   the page title and meta description).  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param blog_id Platform-native numeric blog id. Non-numeric values return 400.
+  # @param create_blog_article_request 
+  # @param [Hash] opts the optional parameters
+  # @return [CreateBlogArticle201Response]
+  describe 'create_blog_article test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for delete_blog
+  # Delete a blog
+  # Deletes the blog AND every article in it. The delete happens on the platform and is permanent; Zernio stores nothing to restore it from.  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param blog_id Platform-native numeric blog id. Non-numeric values return 400.
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'delete_blog test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for delete_blog_article
+  # Delete a blog article
+  # Deletes the article. The delete happens on the platform and is permanent; Zernio stores nothing to restore it from.  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param blog_id Platform-native numeric blog id. Non-numeric values return 400.
+  # @param article_id Platform-native numeric article id. Non-numeric values return 400.
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'delete_blog_article test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for get_blog
+  # Get a blog
+  # Fetches a single blog. `blogId` is the platform's numeric blog id from `GET /v1/accounts/{accountId}/blogs`, not a Zernio id.  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param blog_id Platform-native numeric blog id. Non-numeric values return 400.
+  # @param [Hash] opts the optional parameters
+  # @return [CreateBlog201Response]
+  describe 'get_blog test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for get_blog_article
+  # Get a blog article
+  # Fetches a single article. An article addressed through a blog it does not belong to is a 404 (code blog_article_not_found).  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param blog_id Platform-native numeric blog id. Non-numeric values return 400.
+  # @param article_id Platform-native numeric article id. Non-numeric values return 400.
+  # @param [Hash] opts the optional parameters
+  # @return [CreateBlogArticle201Response]
+  describe 'get_blog_article test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for list_blog_articles
+  # List blog articles
+  # Lists the articles of a blog. Cursor-paginated: pass `limit` (1-50, default 20) and the `cursor` from a previous response's `nextCursor`; `nextCursor` is null when there are no more pages.  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param blog_id Platform-native numeric blog id. Non-numeric values return 400.
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :limit Page size (1-50).
+  # @option opts [String] :cursor Opaque cursor from a previous response. Omit for the first page.
+  # @return [ListBlogArticles200Response]
+  describe 'list_blog_articles test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for list_blogs
+  # List blogs
+  # Lists the blogs on the connected store, newest-first as the platform returns them. Cursor-paginated: pass `limit` (1-50, default 20) and the `cursor` from a previous response's `nextCursor`; `nextCursor` is null when there are no more pages.  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :limit Page size (1-50).
+  # @option opts [String] :cursor Opaque cursor from a previous response. Omit for the first page.
+  # @return [ListBlogs200Response]
+  describe 'list_blogs test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for update_blog
+  # Update a blog
+  # Partial-updates a blog. Send any subset of `title` and `handle`; at least one field is required (an empty body returns 400).  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param blog_id Platform-native numeric blog id. Non-numeric values return 400.
+  # @param update_blog_request 
+  # @param [Hash] opts the optional parameters
+  # @return [CreateBlog201Response]
+  describe 'update_blog test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  # unit tests for update_blog_article
+  # Update a blog article
+  # Partial-updates an article. Send any subset of the create fields (`title`, `bodyHtml`, `handle`, `tags`, `author`, `excerpt`, `image`, `seo`, `isPublished`, `publishDate`); at least one field is required (an empty body returns 400). `isPublished` and `publishDate` behave as on create: `isPublished: false` unpublishes back to a draft and a future `publishDate` schedules publication natively on the platform.  Supported on Shopify (platform `shopify`). Accounts on platforms without blogs support return 400; a blogs-capable platform that lacks this specific operation returns 405. 
+  # @param account_id Connected Shopify SocialAccount id.
+  # @param blog_id Platform-native numeric blog id. Non-numeric values return 400.
+  # @param article_id Platform-native numeric article id. Non-numeric values return 400.
+  # @param update_blog_article_request 
+  # @param [Hash] opts the optional parameters
+  # @return [CreateBlogArticle201Response]
+  describe 'update_blog_article test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+end

data/spec/api/comments_api_spec.rb

@@ -37,7 +37,7 @@ describe 'CommentsApi' do
   # Delete a comment on a post. Supported by Facebook, Instagram, Bluesky, Reddit, YouTube, and LinkedIn. Requires accountId and commentId query parameters. 
   # @param post_id Zernio post ID or platform-specific post ID. LinkedIn third-party posts accept full activity URN or numeric ID.
   # @param account_id 
-  # @param comment_id 
+  # @param comment_id For LinkedIn, accepts either the numeric comment ID or the composite comment URN returned by the comments listing (e.g. urn:li:comment:(threadUrn,id))
   # @param [Hash] opts the optional parameters
   # @return [DeleteInboxComment200Response]
   describe 'delete_inbox_comment test' do
@@ -62,13 +62,13 @@ describe 'CommentsApi' do
 
   # unit tests for get_inbox_post_comments
   # Get post comments
-  # Fetch comments for a specific post. Requires accountId query parameter.
-  # @param post_id Zernio post ID or platform-specific post ID. Zernio IDs are auto-resolved. LinkedIn third-party posts accept full activity URN or numeric ID.
+  # Fetch comments for a specific post. Requires accountId query parameter.  On Facebook and Instagram, passing a COMMENT id as `postId` is also supported and returns that comment's replies instead of the post's top-level comments. This is not available on YouTube, where `postId` must be a video id. 
+  # @param post_id Zernio post ID or platform-specific post ID. Zernio IDs are auto-resolved. LinkedIn third-party posts accept full activity URN or numeric ID. On Facebook and Instagram, a comment ID is also accepted here and returns that comment's replies.
   # @param account_id 
   # @param [Hash] opts the optional parameters
   # @option opts [String] :subreddit (Reddit only) Subreddit name
   # @option opts [Integer] :limit Maximum number of comments to return
-  # @option opts [String] :cursor Pagination cursor
+  # @option opts [String] :cursor Pagination cursor, returned by a previous call as `pagination.cursor`. This is the platform's own opaque paging value passed through verbatim: never construct, decode or validate it client-side.
   # @option opts [String] :comment_id (Reddit only) Get replies to a specific comment
   # @return [GetInboxPostComments200Response]
   describe 'get_inbox_post_comments test' do
@@ -120,7 +120,7 @@ describe 'CommentsApi' do
 
   # unit tests for list_inbox_comments
   # List commented posts
-  # Returns posts with comment counts from all connected accounts. Aggregates data across multiple accounts.  For users with the Ads add-on (Metronome plans always qualify), the user's Meta ads (boosted/dark posts) are included too. There's one row per (ad, placement-with-comments): an ad that runs on both Facebook feed and Instagram feed produces up to two rows (the Page dark post and the IG media have separate comment threads), each flagged `isAd: true` with `adId` and `placement` (`id` is `{adId}:{placement}`). Use `?platform=metaads` to return *only* ad rows; passing `facebook`/`instagram` returns *organic* posts only (no ads); omitting `platform` returns both. Fetch a row's thread from GET /v1/ads/{adId}/comments?placement={placement}. Ad comment counts are read with the Marketing API token (Facebook side) or the connected Instagram account's token (Instagram side); a row whose count can't be read is omitted.  Pagination walks each account's platform listing. Following `nextCursor` reaches past the first page on Facebook and Instagram only, since they are the platforms that support a server-side date window; on the others the listing stops at its first page. 
+  # Returns posts with comment counts from all connected accounts. Aggregates data across multiple accounts.  For users with the Ads add-on (Metronome plans always qualify), the user's Meta ads (boosted/dark posts) are included too. There's one row per (ad, placement-with-comments): an ad that runs on both Facebook feed and Instagram feed produces up to two rows (the Page dark post and the IG media have separate comment threads), each flagged `isAd: true` with `adId` and `placement` (`id` is `{adId}:{placement}`). Use `?platform=metaads` to return *only* ad rows; passing `facebook`/`instagram` returns *organic* posts only (no ads); omitting `platform` returns both. Fetch a row's thread from GET /v1/ads/{adId}/comments?placement={placement}. Ad comment counts are read with the Marketing API token (Facebook side) or the connected Instagram account's token (Instagram side); a row whose count can't be read is omitted.  Pagination walks each account's platform listing. Following `nextCursor` reaches past the first page on Facebook, Instagram, Threads, LinkedIn and YouTube, since they are the platforms that support a server-side date window; on the others the listing stops at its first page. Cursor pagination is only coherent for the default sort (`sortBy=date`, `sortOrder=desc`): with `sortOrder=asc`, or with `sortBy=comments`, the cursor filter does not match the sort order and the second page is unreliable.  `nextCursor` is opaque: pass it back verbatim, never construct or parse it, its composition may change without notice. Because each page re-queries a live window, results can still shift between requests, so dedupe by `id` on the client.  `commentCount` semantics differ by platform: YouTube's includes replies, Facebook's counts top-level comments only. 
   # @param [Hash] opts the optional parameters
   # @option opts [String] :profile_id Filter by profile ID
   # @option opts [String] :platform Filter by platform. `metaads` is a synthetic value meaning the user's ads (boosted/dark posts) only; `facebook`/`instagram` return organic posts only.

data/spec/api/connect_api_spec.rb

@@ -125,6 +125,18 @@ describe 'ConnectApi' do
     end
   end
 
+  # unit tests for connect_shopify_with_token
+  # Connect a Shopify store with a custom-app Admin token
+  # Token-paste alternative to the OAuth flow: connect a store using the Admin API access token of a custom app the merchant created in their own Shopify admin (Settings → Apps and sales channels → Develop apps, with the `read_content`/`write_content` scopes). Use this when the one-click OAuth connect is unavailable or when your users prefer not to install a third-party app on their store. The token is validated against the store before anything is saved; custom-app tokens do not expire. Connecting the same profile to a store again replaces the stored token in place. 
+  # @param connect_shopify_with_token_request 
+  # @param [Hash] opts the optional parameters
+  # @return [ConnectShopifyWithToken200Response]
+  describe 'connect_shopify_with_token test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
   # unit tests for connect_whats_app_credentials
   # Connect WhatsApp via credentials
   # Connect a WhatsApp Business Account by providing Meta credentials directly. This is the headless alternative to the Embedded Signup browser flow.  To get the required credentials: 1. Go to Meta Business Suite (business.facebook.com) 2. Create or select a WhatsApp Business Account 3. In Business Settings > System Users, create a System User 4. Assign it the whatsapp_business_management and whatsapp_business_messaging permissions 5. Generate a permanent access token 6. Get the WABA ID from WhatsApp Manager > Account Tools > Phone Numbers 7. Get the Phone Number ID from the same page (click on the number) 
@@ -159,6 +171,7 @@ describe 'ConnectApi' do
   # @option opts [String] :redirect_url Your custom redirect URL after connection completes. Accepts an http(s) URL, a custom app scheme for mobile deeplinks (e.g. myapp://callback), or a relative path. Result params are appended with the URL API, so an existing query string is preserved. Standard mode appends connected={platform}&profileId=X&accountId=Y&username=Z. Headless mode appends OAuth data params for platforms requiring selection (e.g. LinkedIn orgs, Facebook pages). If no selection is needed, the account is created directly and the redirect includes accountId.
   # @option opts [Boolean] :headless When true, the user is redirected to your redirect_url with raw OAuth data (code, state) instead of Zernio's default account selection UI. Use this to build a custom connect experience.
   # @option opts [String] :login_method Instagram only. Which of the two Instagram connection methods to use. Ignored for every other platform.  `instagram_login` (the default, and what you get if you omit this): the Instagram Login dialog. The user authorizes their Instagram professional account directly, no Facebook Page required.  `facebook_login`: the Facebook Login dialog, i.e. \"Instagram API with Facebook Login\". The user authorizes a Facebook Page that has a linked Instagram professional account, and every API call for that account then runs through the Page. Use this when the customer manages Instagram through a Page and expects the Facebook consent screen. Because the user has to pick which Page to connect, the callback continues at the account-selection step, `/v1/connect/instagram/select-account`.  `facebook_login` supports `headless=true` like the other selection platforms: the callback redirects to your `redirect_url` with `profileId`, `tempToken`, `platform=instagram`, `step=select_account` and `connect_token`, which you pass into the select-account endpoints to finish. The default `instagram_login` has no selection step, so it connects the account directly. 
+  # @option opts [String] :onboarding WhatsApp only. Ignored for every other platform. Controls which screen Meta's Embedded Signup popup shows.  If omitted, the connection defaults to coexistence (same as `business_app` below), preserving existing behavior for numbers already on the WhatsApp Business app.  `api`: standard Embedded Signup, showing Meta's WABA/number picker. Use this to connect a phone number already on Cloud API elsewhere.  `business_app`: coexistence, i.e. 'Connect existing WhatsApp Business app' (a number shared between Cloud API and the consumer WhatsApp Business app). 
   # @return [GetConnectUrl200Response]
   describe 'get_connect_url test' do
     it 'should work' do
@@ -255,6 +268,20 @@ describe 'ConnectApi' do
     end
   end
 
+  # unit tests for get_shopify_connect_url
+  # Get Shopify OAuth connect URL
+  # Initiate the Shopify OAuth flow for a store. Shopify is a connect-only platform: the connected account does not publish social posts, it powers the Blogs API (`/v1/accounts/{accountId}/blogs`). Returns an `authUrl` to redirect the merchant to; after they approve the install, Shopify redirects their browser to Zernio's callback, the account is created on the profile (platform `shopify`), and the browser is redirected to `redirect_url` (or the Zernio dashboard when omitted). Requested scopes are `read_content` and `write_content` (content only; no customer or order data). Connecting the same profile to a store again refreshes the stored token in place. 
+  # @param profile_id Your Zernio profile ID (get from /v1/profiles).
+  # @param shop The myshopify.com store domain to connect, e.g. `your-store.myshopify.com` (the bare `your-store` prefix is accepted too).
+  # @param [Hash] opts the optional parameters
+  # @option opts [String] :redirect_url Your custom redirect URL after connection completes. Accepts an http(s) URL, a custom app scheme for mobile deeplinks (e.g. myapp://callback), or a relative path. On failure an `error` query param is appended.
+  # @return [GetConnectUrl200Response]
+  describe 'get_shopify_connect_url test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
   # unit tests for get_subreddit_rules
   # Get subreddit rules
   # Returns a subreddit's posting rules plus Reddit's site-wide rules, so you can check them before submitting and avoid a removal.  Use this alongside `POST /v1/tools/validate/subreddit`, which only confirms that a subreddit exists and reports its basic posting settings. 

data/spec/api/messages_api_spec.rb

@@ -106,7 +106,7 @@ describe 'MessagesApi' do
   # @param account_id Social account ID
   # @param [Hash] opts the optional parameters
   # @option opts [Integer] :limit Number of messages to return per page. Default 100, max 100.
-  # @option opts [String] :cursor Opaque pagination cursor. Pass `pagination.nextCursor` from a prior response.
+  # @option opts [String] :cursor Opaque pagination cursor. Pass `pagination.nextCursor` from a prior response verbatim: a cursor we cannot parse returns 400 rather than silently restarting from the first page.
   # @option opts [String] :sort_order Order of returned messages. Default `asc` (oldest first, chat style). Twitter, Instagram, Telegram, WhatsApp and Reddit honor this order across cursor pages. For Facebook and Bluesky, only intra-page ordering is affected — pages always walk newest→oldest. See `sortOrderApplied` in the response. 
   # @return [GetInboxConversationMessages200Response]
   describe 'get_inbox_conversation_messages test' do
@@ -186,7 +186,7 @@ describe 'MessagesApi' do
   # @option opts [String] :platform Filter by platform (searchable platforms only)
   # @option opts [String] :account_id Filter by specific social account ID
   # @option opts [Integer] :limit Maximum number of conversations to return
-  # @option opts [String] :cursor Pagination cursor for next page
+  # @option opts [String] :cursor Opaque pagination cursor. Pass back pagination.nextCursor verbatim; do not construct one.
   # @return [SearchInboxConversations200Response]
   describe 'search_inbox_conversations test' do
     it 'should work' do

data/spec/api/posts_api_spec.rb

@@ -47,7 +47,7 @@ describe 'PostsApi' do
 
   # unit tests for create_post
   # Create post
-  # Create and optionally publish a post. Immediate posts (`publishNow: true`) include `platformPostUrl` in the response. Content is optional when media is attached or all platforms have `customContent`. See each platform's schema for media constraints.  ## Idempotency  Two layers of duplicate-protection apply, so safe-to-retry callers (network blips, n8n / Zapier retries, etc.) don't accidentally double-post.  **1. Same-request idempotency (5-minute window).** Pass an `x-request-id` header to mark a logical request. If a second request arrives with the same `x-request-id` while the first is in-flight (or within ~5 minutes of completion), we return **HTTP 200** with the original post in the `existingPost` field — no new post is created. The official Zernio SDKs auto-generate a unique `x-request-id` per call. If you're using a generic HTTP client (curl, n8n's HTTP node, Zapier, custom code), either: - Set a unique `x-request-id` per logical call (recommended — UUIDv4 is fine) - Or simply omit the header — we'll treat each request as new  **Common pitfall**: if your workflow tool uses a single execution-level request ID and reuses it across multiple HTTP nodes (e.g. one ID for the whole run, shared across 6 different platform calls), every call after the first will look like a retry of the first and return its post. Generate a fresh ID per node.  **2. Content-hash dedup (24-hour window).** Independently, we hash `(platform, accountId, content + media URLs)` and reject duplicates within 24 hours with **HTTP 409**. This catches genuine \"same content posted twice to the same account\" cases regardless of `x-request-id`. Returns `error`, `accountId`, `platform`, and `existingPostId` so you can find the original. To intentionally re-post identical content within 24h, change something (the caption, the media, the account) — the dedup is keyed on the full content fingerprint.  Order: same-`x-request-id` retries (200) are checked first; if no idempotency match, the content-hash dedup (409) runs. 
+  # Create and optionally publish a post. Immediate posts (`publishNow: true`) include `platformPostUrl` in the response. Content is optional when media is attached, all platforms have `customContent`, every platform entry is an X Article (`platformSpecificData.article`), or every platform entry is a LinkedIn plain repost (`platformSpecificData.reshareUrl` with no text). See each platform's schema for media constraints.  ## Idempotency  Two layers of duplicate-protection apply, so safe-to-retry callers (network blips, n8n / Zapier retries, etc.) don't accidentally double-post.  **1. Same-request idempotency (5-minute window).** Pass an `x-request-id` header to mark a logical request. If a second request arrives with the same `x-request-id` while the first is in-flight (or within ~5 minutes of completion), we return **HTTP 200** with the original post in the `existingPost` field — no new post is created. The official Zernio SDKs auto-generate a unique `x-request-id` per call. If you're using a generic HTTP client (curl, n8n's HTTP node, Zapier, custom code), either: - Set a unique `x-request-id` per logical call (recommended — UUIDv4 is fine) - Or simply omit the header — we'll treat each request as new  **Common pitfall**: if your workflow tool uses a single execution-level request ID and reuses it across multiple HTTP nodes (e.g. one ID for the whole run, shared across 6 different platform calls), every call after the first will look like a retry of the first and return its post. Generate a fresh ID per node.  **2. Content-hash dedup (24-hour window).** Independently, we hash `(platform, accountId, content + media URLs)` and reject duplicates within 24 hours with **HTTP 409**. This catches genuine \"same content posted twice to the same account\" cases regardless of `x-request-id`. Returns `error`, `accountId`, `platform`, and `existingPostId` so you can find the original. To intentionally re-post identical content within 24h, change something (the caption, the media, the account) — the dedup is keyed on the full content fingerprint.  Order: same-`x-request-id` retries (200) are checked first; if no idempotency match, the content-hash dedup (409) runs. 
   # @param create_post_request 
   # @param [Hash] opts the optional parameters
   # @option opts [String] :x_request_id Optional client-generated request identifier for safe retry (idempotency). When two requests carry the same value, the second is treated as a retry of the first and returns the original post (HTTP 200) instead of creating a duplicate. Window is ~5 minutes from the first request. Generate a UUID per logical call. SDKs do this automatically; HTTP clients should set it themselves or omit it. See the operation description for the full idempotency contract. 

data/spec/api/sms_api_spec.rb

@@ -226,7 +226,7 @@ describe 'SMSApi' do
 
   # unit tests for send_sms
   # Send an SMS/MMS
-  # Sends an SMS (or MMS when `mediaUrls` is set) from one of your SMS-enabled numbers. At least one of `text` / `mediaUrls` is required. Both numbers are normalized to E.164, so `from` matches regardless of formatting and replies thread into the same inbox conversation.  US numbers must have an approved carrier registration (`/v1/sms/registrations`) before messages deliver.  **Idempotency:** send an `Idempotency-Key` header to make retries safe: same key + same body replays the original response instead of sending a second message; same key + different body returns 422; a key still in flight returns 409. 
+  # Sends an SMS (or MMS when `mediaUrls` is set) from one of your SMS-enabled numbers. At least one of `text` / `mediaUrls` is required. Both numbers are normalized to E.164, so `from` matches regardless of formatting and replies thread into the same inbox conversation.  US numbers must have an approved carrier registration (`/v1/sms/registrations`) before messages deliver.  **Replies and delivery status arrive as webhooks**, not by polling: an inbound reply fires `message.received` with `platform: \"sms\"`, the first message of a new thread also fires `conversation.started`, and this message's own outcome fires `message.delivered` or `message.failed` (the latter carrying the carrier's error code).  **Opted-out recipients:** a send to a number that replied STOP is refused with `409`, never silently dropped.  **Idempotency:** send an `Idempotency-Key` header to make retries safe: same key + same body replays the original response instead of sending a second message; same key + different body returns 422; a key still in flight returns 409. 
   # @param send_sms_request 
   # @param [Hash] opts the optional parameters
   # @option opts [String] :idempotency_key Optional client-generated unique key (e.g. a UUID) that makes retries safe. Same key + same body replays the original response; same key + different body → 422; key still processing → 409.

data/spec/api/whats_app_api_spec.rb

@@ -297,6 +297,19 @@ describe 'WhatsAppApi' do
     end
   end
 
+  # unit tests for list_whats_app_account_events
+  # List account notifications
+  # Returns Meta-originated events recorded for a WhatsApp account, newest first: template review outcomes (approved, rejected, paused, category changes) and WABA status changes (restricted, disabled, reinstated, disconnected). Events are captured from Meta webhooks as they happen; the feed starts at the account's first recorded event and is not backfilled. Complements the push events `whatsapp.template.status_updated` and `account.disconnected` with a pollable history. 
+  # @param account_id WhatsApp social account ID
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :limit Maximum events to return
+  # @return [ListWhatsAppAccountEvents200Response]
+  describe 'list_whats_app_account_events test' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
   # unit tests for list_whats_app_conversions
   # List conversion events
   # Returns the most recent conversion events sent through `POST /v1/whatsapp/conversions` for the given WhatsApp account. Sourced from delivery logs (Axiom `late` dataset), so the visible window is bounded by log retention (about 30 days). Useful for rendering a \"recent activity\" panel on the conversions setup tab without standing up a parallel persistence layer.  Per-event payload mirrors the structured log we write on every successful send: `eventName`, `conversationId`, `eventsReceived`, `eventsFailed`, `traceId`, `durationMs`, and the wall-clock `timestamp`. 

data/spec/models/account_with_follower_stats_spec.rb

@@ -36,7 +36,7 @@ describe Zernio::AccountWithFollowerStats do
   describe 'test attribute "platform"' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
-      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["tiktok", "instagram", "facebook", "youtube", "linkedin", "twitter", "threads", "pinterest", "reddit", "bluesky", "googlebusiness", "telegram", "snapchat", "discord", "slack", "whatsapp", "linkedinads", "metaads", "pinterestads", "tiktokads", "xads", "googleads", "openaiads"])
+      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["tiktok", "instagram", "facebook", "youtube", "linkedin", "twitter", "threads", "pinterest", "reddit", "bluesky", "googlebusiness", "telegram", "snapchat", "discord", "slack", "whatsapp", "linkedinads", "metaads", "pinterestads", "tiktokads", "xads", "googleads", "openaiads", "sms", "phone", "rcs"])
       # validator.allowable_values.each do |value|
       #   expect { instance.platform = value }.not_to raise_error
       # end

data/spec/models/ad_creative_spec.rb

@@ -51,6 +51,12 @@ describe Zernio::AdCreative do
     end
   end
 
+  describe 'test attribute "creative_id"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
   describe 'test attribute "object_type"' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/

data/spec/models/analytics_list_response_posts_inner_media_items_inner_spec.rb

@@ -0,0 +1,58 @@
+=begin
+#Zernio API
+
+#API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api 
+
+The version of the OpenAPI document: 1.0.4
+Contact: support@zernio.com
+Generated by: https://openapi-generator.tech
+Generator version: 7.19.0
+
+=end
+
+require 'spec_helper'
+require 'json'
+require 'date'
+
+# Unit tests for Zernio::AnalyticsListResponsePostsInnerMediaItemsInner
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe Zernio::AnalyticsListResponsePostsInnerMediaItemsInner do
+  #let(:instance) { Zernio::AnalyticsListResponsePostsInnerMediaItemsInner.new }
+
+  describe 'test an instance of AnalyticsListResponsePostsInnerMediaItemsInner' do
+    it 'should create an instance of AnalyticsListResponsePostsInnerMediaItemsInner' do
+      # uncomment below to test the instance creation
+      #expect(instance).to be_instance_of(Zernio::AnalyticsListResponsePostsInnerMediaItemsInner)
+    end
+  end
+
+  describe 'test attribute "type"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["image", "video"])
+      # validator.allowable_values.each do |value|
+      #   expect { instance.type = value }.not_to raise_error
+      # end
+    end
+  end
+
+  describe 'test attribute "url"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "thumbnail"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+  describe 'test attribute "alt_text"' do
+    it 'should work' do
+      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
+    end
+  end
+
+end