late-sdk 0.0.891 → 0.0.893

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8f562746b718328fd8d6f0f4ffadb1e841b30ffc494dffeaeae2d1e4deb40e40
-  data.tar.gz: 3d269d5d7149ba25c46d70a8f2c836fdd833bbff65cde06f02adcd469ccf813d
+  metadata.gz: 5fd86ce35443db934013c4d93c88919a14e76e18b33a8840e77b66df3e2b37c5
+  data.tar.gz: 6acff42012ff43c583b90aec95d96c1f478b718b824ffc27f3c77bf62f4e2f3f
 SHA512:
-  metadata.gz: b1cfd089b27b371e9cf2033858045e9489e151f08dafee470fb874b1d4ea16e89287b0f2ffa03da57406c59de5bdf5e546e99b3fd1c473a033ded04bd48c72a3
-  data.tar.gz: 393ba287e92510fe9a06c36e00c208b81d59a5728165fa2ad2579159226d297839aa255d00c4c2ce65c725c043943994adb227f37921692cf09f69de4d241296
+  metadata.gz: 79779669ded9119cee41725c590efdbc831ae40170b90ac51b007fe41e0510608942835ee39817cad5ba68cd2fab60a8cd09c4404d4378d061194f710fcaed99
+  data.tar.gz: ee18055cb92d12bf2b1d1845f9e0f5f50777a6649156a2f030bb25c5f4d2451296567366fdd95f18c5d07eed27adcbb025e65129498b1695d863bd2933862981

data/README.md

@@ -979,7 +979,6 @@ Class | Method | HTTP request | Description
  - [Zernio::Connected](docs/Connected.md)
  - [Zernio::ConnectedAccount](docs/ConnectedAccount.md)
  - [Zernio::ConnectedApp](docs/ConnectedApp.md)
- - [Zernio::Conversation](docs/Conversation.md)
  - [Zernio::ConversionAction](docs/ConversionAction.md)
  - [Zernio::ConversionActionTagSnippetsInner](docs/ConversionActionTagSnippetsInner.md)
  - [Zernio::ConversionDestination](docs/ConversionDestination.md)
@@ -1655,6 +1654,7 @@ Class | Method | HTTP request | Description
  - [Zernio::InboxMessageEditHistoryEntry](docs/InboxMessageEditHistoryEntry.md)
  - [Zernio::InboxWebhookAccount](docs/InboxWebhookAccount.md)
  - [Zernio::InboxWebhookConversation](docs/InboxWebhookConversation.md)
+ - [Zernio::InboxWebhookConversationDetail](docs/InboxWebhookConversationDetail.md)
  - [Zernio::InboxWebhookMessage](docs/InboxWebhookMessage.md)
  - [Zernio::InboxWebhookMessageAttachmentsInner](docs/InboxWebhookMessageAttachmentsInner.md)
  - [Zernio::InboxWebhookMessageSender](docs/InboxWebhookMessageSender.md)
@@ -2569,7 +2569,6 @@ Class | Method | HTTP request | Description
  - [Zernio::WebhookPayloadConversationControlChanged](docs/WebhookPayloadConversationControlChanged.md)
  - [Zernio::WebhookPayloadConversationControlChangedControl](docs/WebhookPayloadConversationControlChangedControl.md)
  - [Zernio::WebhookPayloadConversationStarted](docs/WebhookPayloadConversationStarted.md)
- - [Zernio::WebhookPayloadConversationStartedConversation](docs/WebhookPayloadConversationStartedConversation.md)
  - [Zernio::WebhookPayloadExternalPost](docs/WebhookPayloadExternalPost.md)
  - [Zernio::WebhookPayloadLead](docs/WebhookPayloadLead.md)
  - [Zernio::WebhookPayloadLeadAccount](docs/WebhookPayloadLeadAccount.md)

data/docs/AnalyticsApi.md

@@ -129,7 +129,7 @@ end
 
 Analytics changed since a cursor
 
-Cursor feed of the analytics snapshots that CHANGED, across every account you can read, in one paginated stream. Built for integrations that would otherwise call `GET /v1/analytics` once per connected account. Each page carries changes from many accounts at once, so your call count scales with how much actually changed rather than with how many accounts you have. Measured against a fleet of roughly 1,600 connected accounts: about 1,599 per-account analytics calls an hour became about 205 delta calls an hour, a 7.8x reduction.  **Bootstrap once, then stay in sync.** Load your baseline from `GET /v1/analytics`, which is the historical endpoint. This one is a rolling 7-day change log and cannot replay history. Then call this endpoint with NO `cursor`: it answers with an empty `data` array plus the feed's current position in `nextCursor`. Send that `nextCursor` back on the next call and you receive everything written since. `nextCursor` is present on every response, empty pages included, so you always have something to advance with.  **Ordering.** Entries come back oldest first, in the order the feed received them. That order is NOT `syncedAt`: `syncedAt` is stamped when an account's sync cycle started, and a slow cycle writes its rows after a faster cycle that started later, so `syncedAt` can go backwards between consecutive entries. Do not sort, filter or resume on it. The cursor is the only stable position, and it is opaque: pass it back verbatim, and do not parse, construct or compare cursors.  **`hasMore: false` does not mean the feed ended.** This stream has no end and `nextCursor` is never null. `hasMore: true` means more changes are already waiting, so call again straight away. `hasMore: false` means you are caught up: keep the cursor and poll again on your normal interval.  **The newest changes settle before they are served.** The feed deliberately holds back its last few seconds of writes, so that a row can never become visible behind a cursor you have already advanced past. A read issued the instant an `analytics.synced` webhook lands will therefore often return an empty page for that account. Do not read an empty page as \"nothing changed\": poll again with the SAME cursor you last used rather than advancing.  **Repeats inside one instant.** A sync cycle occasionally records the same post twice at the same feed position. When that happens the feed delivers one of those rows, not both. Measured over a day of production traffic, about 1.3% of rows fall in such a group and 99.4% of those groups are identical rows, so this is far more often deduplication than loss. Metrics are absolute values rather than increments, so a later entry for the same post supersedes an earlier one.  **Retention is 7 days.** Changes older than that leave the feed. A cursor older than 6 days is rejected with a `400` (a day of margin, because expiry is lazy). Recover by re-bootstrapping from `GET /v1/analytics` and taking a fresh cursor from a call to this endpoint with no `cursor`. A consumer that polls at least daily never reaches this.  Pairs with the `analytics.synced` webhook, so changes can be read on notification instead of on a timer. That event carries no cursor of its own: keep using the `nextCursor` this endpoint gave you.  Requires the same analytics access as `GET /v1/analytics`, and shares the stricter per-second rate-limit window applied to analytics endpoints. 
+Cursor feed of the analytics snapshots that CHANGED, across every account you can read, in one paginated stream. Built for integrations that would otherwise call `GET /v1/analytics` once per connected account. Each page carries changes from many accounts at once, so your call count scales with how much actually changed rather than with how many accounts you have. Measured against a fleet of roughly 1,600 connected accounts: about 1,599 per-account analytics calls an hour became about 205 delta calls an hour, a 7.8x reduction.  **Bootstrap once, then stay in sync.** Take the cursor FIRST: call this endpoint with NO `cursor` and it answers with an empty `data` array plus the feed's current position in `nextCursor`. Then load your baseline from `GET /v1/analytics`, the historical endpoint, because this one is a rolling 7-day change log and cannot replay history. Then resume from the cursor you took before the baseline. Taking the cursor afterwards instead drops every change that lands while the baseline is loading: it is in neither the row you already read nor the feed you resume behind it. The overlap this order creates is safe, because metrics are absolute values rather than increments, so draining it leaves every post on its newest value. `nextCursor` is present on every response, empty pages included, so you always have something to advance with.  **Ordering.** Entries come back oldest first, in the order the feed received them. That order is NOT `syncedAt`: `syncedAt` is stamped when an account's sync cycle started, and a slow cycle writes its rows after a faster cycle that started later, so `syncedAt` can go backwards between consecutive entries. Do not sort, filter or resume on it. The cursor is the only stable position, and it is opaque: pass it back verbatim, and do not parse, construct or compare cursors.  **`hasMore: false` does not mean the feed ended.** This stream has no end and `nextCursor` is never null. `hasMore: true` means more changes are already waiting, so call again straight away. `hasMore: false` means you are caught up: keep the cursor and poll again on your normal interval.  **The newest changes settle before they are served.** The feed deliberately holds back its last few seconds of writes, so that a row can never become visible behind a cursor you have already advanced past. A read issued the instant an `analytics.synced` webhook lands will therefore often return an empty page for that account. Do not read an empty page as \"nothing changed\": poll again with the SAME cursor you last used rather than advancing.  **Repeats inside one instant.** A sync cycle occasionally records the same post twice at the same feed position. When that happens the feed delivers one of those rows, not both. Measured over a day of production traffic, about 1.3% of rows fall in such a group and 99.4% of those groups are identical rows, so this is far more often deduplication than loss. Metrics are absolute values rather than increments, so a later entry for the same post supersedes an earlier one.  **Retention is 7 days.** Changes older than that leave the feed. A cursor older than 6 days is rejected with a `400` (a day of margin, because expiry is lazy). Recover the same way you bootstrapped: take a fresh cursor from a call to this endpoint with no `cursor`, then re-load from `GET /v1/analytics`, then resume from that cursor. A consumer that polls at least daily never reaches this.  Pairs with the `analytics.synced` webhook, so changes can be read on notification instead of on a timer. That event carries no cursor of its own: keep using the `nextCursor` this endpoint gave you.  Requires the same analytics access as `GET /v1/analytics`, and shares the stricter per-second rate-limit window applied to analytics endpoints. 
 
 ### Examples
 

data/docs/{Conversation.md → InboxWebhookConversationDetail.md}

@@ -1,4 +1,4 @@
-# Zernio::Conversation
+# Zernio::InboxWebhookConversationDetail
 
 ## Properties
 
@@ -19,7 +19,7 @@
 ```ruby
 require 'zernio-sdk'
 
-instance = Zernio::Conversation.new(
+instance = Zernio::InboxWebhookConversationDetail.new(
   id: null,
   platform: null,
   platform_conversation_id: null,

data/docs/WebhookPayloadConversationControlChanged.md

@@ -6,7 +6,7 @@
 | ---- | ---- | ----------- | ----- |
 | **id** | **String** | Stable webhook event ID |  |
 | **event** | **String** |  |  |
-| **conversation** | [**WebhookPayloadConversationStartedConversation**](WebhookPayloadConversationStartedConversation.md) |  |  |
+| **conversation** | [**InboxWebhookConversationDetail**](InboxWebhookConversationDetail.md) |  |  |
 | **account** | [**InboxWebhookAccount**](InboxWebhookAccount.md) |  |  |
 | **control** | [**WebhookPayloadConversationControlChangedControl**](WebhookPayloadConversationControlChangedControl.md) |  |  |
 | **changed_at** | **Time** |  |  |

data/docs/WebhookPayloadConversationStarted.md

@@ -6,7 +6,7 @@
 | ---- | ---- | ----------- | ----- |
 | **id** | **String** | Stable webhook event ID |  |
 | **event** | **String** |  |  |
-| **conversation** | [**WebhookPayloadConversationStartedConversation**](WebhookPayloadConversationStartedConversation.md) |  |  |
+| **conversation** | [**InboxWebhookConversationDetail**](InboxWebhookConversationDetail.md) |  |  |
 | **account** | [**InboxWebhookAccount**](InboxWebhookAccount.md) |  |  |
 | **started_at** | **Time** | When the conversation document was created. |  |
 | **timestamp** | **Time** | UTC time at which Zernio generated this event (set once when the event payload is built, before delivery is queued). Retries and redeliveries keep the original value, so it reflects the event, not the delivery attempt. |  |

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

@@ -134,7 +134,7 @@ module Zernio
     end
 
     # Analytics changed since a cursor
-    # Cursor feed of the analytics snapshots that CHANGED, across every account you can read, in one paginated stream. Built for integrations that would otherwise call `GET /v1/analytics` once per connected account. Each page carries changes from many accounts at once, so your call count scales with how much actually changed rather than with how many accounts you have. Measured against a fleet of roughly 1,600 connected accounts: about 1,599 per-account analytics calls an hour became about 205 delta calls an hour, a 7.8x reduction.  **Bootstrap once, then stay in sync.** Load your baseline from `GET /v1/analytics`, which is the historical endpoint. This one is a rolling 7-day change log and cannot replay history. Then call this endpoint with NO `cursor`: it answers with an empty `data` array plus the feed's current position in `nextCursor`. Send that `nextCursor` back on the next call and you receive everything written since. `nextCursor` is present on every response, empty pages included, so you always have something to advance with.  **Ordering.** Entries come back oldest first, in the order the feed received them. That order is NOT `syncedAt`: `syncedAt` is stamped when an account's sync cycle started, and a slow cycle writes its rows after a faster cycle that started later, so `syncedAt` can go backwards between consecutive entries. Do not sort, filter or resume on it. The cursor is the only stable position, and it is opaque: pass it back verbatim, and do not parse, construct or compare cursors.  **`hasMore: false` does not mean the feed ended.** This stream has no end and `nextCursor` is never null. `hasMore: true` means more changes are already waiting, so call again straight away. `hasMore: false` means you are caught up: keep the cursor and poll again on your normal interval.  **The newest changes settle before they are served.** The feed deliberately holds back its last few seconds of writes, so that a row can never become visible behind a cursor you have already advanced past. A read issued the instant an `analytics.synced` webhook lands will therefore often return an empty page for that account. Do not read an empty page as \"nothing changed\": poll again with the SAME cursor you last used rather than advancing.  **Repeats inside one instant.** A sync cycle occasionally records the same post twice at the same feed position. When that happens the feed delivers one of those rows, not both. Measured over a day of production traffic, about 1.3% of rows fall in such a group and 99.4% of those groups are identical rows, so this is far more often deduplication than loss. Metrics are absolute values rather than increments, so a later entry for the same post supersedes an earlier one.  **Retention is 7 days.** Changes older than that leave the feed. A cursor older than 6 days is rejected with a `400` (a day of margin, because expiry is lazy). Recover by re-bootstrapping from `GET /v1/analytics` and taking a fresh cursor from a call to this endpoint with no `cursor`. A consumer that polls at least daily never reaches this.  Pairs with the `analytics.synced` webhook, so changes can be read on notification instead of on a timer. That event carries no cursor of its own: keep using the `nextCursor` this endpoint gave you.  Requires the same analytics access as `GET /v1/analytics`, and shares the stricter per-second rate-limit window applied to analytics endpoints. 
+    # Cursor feed of the analytics snapshots that CHANGED, across every account you can read, in one paginated stream. Built for integrations that would otherwise call `GET /v1/analytics` once per connected account. Each page carries changes from many accounts at once, so your call count scales with how much actually changed rather than with how many accounts you have. Measured against a fleet of roughly 1,600 connected accounts: about 1,599 per-account analytics calls an hour became about 205 delta calls an hour, a 7.8x reduction.  **Bootstrap once, then stay in sync.** Take the cursor FIRST: call this endpoint with NO `cursor` and it answers with an empty `data` array plus the feed's current position in `nextCursor`. Then load your baseline from `GET /v1/analytics`, the historical endpoint, because this one is a rolling 7-day change log and cannot replay history. Then resume from the cursor you took before the baseline. Taking the cursor afterwards instead drops every change that lands while the baseline is loading: it is in neither the row you already read nor the feed you resume behind it. The overlap this order creates is safe, because metrics are absolute values rather than increments, so draining it leaves every post on its newest value. `nextCursor` is present on every response, empty pages included, so you always have something to advance with.  **Ordering.** Entries come back oldest first, in the order the feed received them. That order is NOT `syncedAt`: `syncedAt` is stamped when an account's sync cycle started, and a slow cycle writes its rows after a faster cycle that started later, so `syncedAt` can go backwards between consecutive entries. Do not sort, filter or resume on it. The cursor is the only stable position, and it is opaque: pass it back verbatim, and do not parse, construct or compare cursors.  **`hasMore: false` does not mean the feed ended.** This stream has no end and `nextCursor` is never null. `hasMore: true` means more changes are already waiting, so call again straight away. `hasMore: false` means you are caught up: keep the cursor and poll again on your normal interval.  **The newest changes settle before they are served.** The feed deliberately holds back its last few seconds of writes, so that a row can never become visible behind a cursor you have already advanced past. A read issued the instant an `analytics.synced` webhook lands will therefore often return an empty page for that account. Do not read an empty page as \"nothing changed\": poll again with the SAME cursor you last used rather than advancing.  **Repeats inside one instant.** A sync cycle occasionally records the same post twice at the same feed position. When that happens the feed delivers one of those rows, not both. Measured over a day of production traffic, about 1.3% of rows fall in such a group and 99.4% of those groups are identical rows, so this is far more often deduplication than loss. Metrics are absolute values rather than increments, so a later entry for the same post supersedes an earlier one.  **Retention is 7 days.** Changes older than that leave the feed. A cursor older than 6 days is rejected with a `400` (a day of margin, because expiry is lazy). Recover the same way you bootstrapped: take a fresh cursor from a call to this endpoint with no `cursor`, then re-load from `GET /v1/analytics`, then resume from that cursor. A consumer that polls at least daily never reaches this.  Pairs with the `analytics.synced` webhook, so changes can be read on notification instead of on a timer. That event carries no cursor of its own: keep using the `nextCursor` this endpoint gave you.  Requires the same analytics access as `GET /v1/analytics`, and shares the stricter per-second rate-limit window applied to analytics endpoints. 
     # @param [Hash] opts the optional parameters
     # @option opts [String] :cursor Opaque cursor from a previous response's `nextCursor`. Omit it to start from now: the response is then an empty page carrying the feed's current position. Rejected with a `400` when malformed, or when older than the retention window. 
     # @option opts [Integer] :limit Page size. Out-of-range values are a 400, never a silent clamp. (default to 50)
@@ -147,7 +147,7 @@ module Zernio
     end
 
     # Analytics changed since a cursor
-    # Cursor feed of the analytics snapshots that CHANGED, across every account you can read, in one paginated stream. Built for integrations that would otherwise call `GET /v1/analytics` once per connected account. Each page carries changes from many accounts at once, so your call count scales with how much actually changed rather than with how many accounts you have. Measured against a fleet of roughly 1,600 connected accounts: about 1,599 per-account analytics calls an hour became about 205 delta calls an hour, a 7.8x reduction.  **Bootstrap once, then stay in sync.** Load your baseline from `GET /v1/analytics`, which is the historical endpoint. This one is a rolling 7-day change log and cannot replay history. Then call this endpoint with NO `cursor`: it answers with an empty `data` array plus the feed's current position in `nextCursor`. Send that `nextCursor` back on the next call and you receive everything written since. `nextCursor` is present on every response, empty pages included, so you always have something to advance with.  **Ordering.** Entries come back oldest first, in the order the feed received them. That order is NOT `syncedAt`: `syncedAt` is stamped when an account's sync cycle started, and a slow cycle writes its rows after a faster cycle that started later, so `syncedAt` can go backwards between consecutive entries. Do not sort, filter or resume on it. The cursor is the only stable position, and it is opaque: pass it back verbatim, and do not parse, construct or compare cursors.  **`hasMore: false` does not mean the feed ended.** This stream has no end and `nextCursor` is never null. `hasMore: true` means more changes are already waiting, so call again straight away. `hasMore: false` means you are caught up: keep the cursor and poll again on your normal interval.  **The newest changes settle before they are served.** The feed deliberately holds back its last few seconds of writes, so that a row can never become visible behind a cursor you have already advanced past. A read issued the instant an `analytics.synced` webhook lands will therefore often return an empty page for that account. Do not read an empty page as \"nothing changed\": poll again with the SAME cursor you last used rather than advancing.  **Repeats inside one instant.** A sync cycle occasionally records the same post twice at the same feed position. When that happens the feed delivers one of those rows, not both. Measured over a day of production traffic, about 1.3% of rows fall in such a group and 99.4% of those groups are identical rows, so this is far more often deduplication than loss. Metrics are absolute values rather than increments, so a later entry for the same post supersedes an earlier one.  **Retention is 7 days.** Changes older than that leave the feed. A cursor older than 6 days is rejected with a `400` (a day of margin, because expiry is lazy). Recover by re-bootstrapping from `GET /v1/analytics` and taking a fresh cursor from a call to this endpoint with no `cursor`. A consumer that polls at least daily never reaches this.  Pairs with the `analytics.synced` webhook, so changes can be read on notification instead of on a timer. That event carries no cursor of its own: keep using the `nextCursor` this endpoint gave you.  Requires the same analytics access as `GET /v1/analytics`, and shares the stricter per-second rate-limit window applied to analytics endpoints. 
+    # Cursor feed of the analytics snapshots that CHANGED, across every account you can read, in one paginated stream. Built for integrations that would otherwise call `GET /v1/analytics` once per connected account. Each page carries changes from many accounts at once, so your call count scales with how much actually changed rather than with how many accounts you have. Measured against a fleet of roughly 1,600 connected accounts: about 1,599 per-account analytics calls an hour became about 205 delta calls an hour, a 7.8x reduction.  **Bootstrap once, then stay in sync.** Take the cursor FIRST: call this endpoint with NO `cursor` and it answers with an empty `data` array plus the feed's current position in `nextCursor`. Then load your baseline from `GET /v1/analytics`, the historical endpoint, because this one is a rolling 7-day change log and cannot replay history. Then resume from the cursor you took before the baseline. Taking the cursor afterwards instead drops every change that lands while the baseline is loading: it is in neither the row you already read nor the feed you resume behind it. The overlap this order creates is safe, because metrics are absolute values rather than increments, so draining it leaves every post on its newest value. `nextCursor` is present on every response, empty pages included, so you always have something to advance with.  **Ordering.** Entries come back oldest first, in the order the feed received them. That order is NOT `syncedAt`: `syncedAt` is stamped when an account's sync cycle started, and a slow cycle writes its rows after a faster cycle that started later, so `syncedAt` can go backwards between consecutive entries. Do not sort, filter or resume on it. The cursor is the only stable position, and it is opaque: pass it back verbatim, and do not parse, construct or compare cursors.  **`hasMore: false` does not mean the feed ended.** This stream has no end and `nextCursor` is never null. `hasMore: true` means more changes are already waiting, so call again straight away. `hasMore: false` means you are caught up: keep the cursor and poll again on your normal interval.  **The newest changes settle before they are served.** The feed deliberately holds back its last few seconds of writes, so that a row can never become visible behind a cursor you have already advanced past. A read issued the instant an `analytics.synced` webhook lands will therefore often return an empty page for that account. Do not read an empty page as \"nothing changed\": poll again with the SAME cursor you last used rather than advancing.  **Repeats inside one instant.** A sync cycle occasionally records the same post twice at the same feed position. When that happens the feed delivers one of those rows, not both. Measured over a day of production traffic, about 1.3% of rows fall in such a group and 99.4% of those groups are identical rows, so this is far more often deduplication than loss. Metrics are absolute values rather than increments, so a later entry for the same post supersedes an earlier one.  **Retention is 7 days.** Changes older than that leave the feed. A cursor older than 6 days is rejected with a `400` (a day of margin, because expiry is lazy). Recover the same way you bootstrapped: take a fresh cursor from a call to this endpoint with no `cursor`, then re-load from `GET /v1/analytics`, then resume from that cursor. A consumer that polls at least daily never reaches this.  Pairs with the `analytics.synced` webhook, so changes can be read on notification instead of on a timer. That event carries no cursor of its own: keep using the `nextCursor` this endpoint gave you.  Requires the same analytics access as `GET /v1/analytics`, and shares the stricter per-second rate-limit window applied to analytics endpoints. 
     # @param [Hash] opts the optional parameters
     # @option opts [String] :cursor Opaque cursor from a previous response's `nextCursor`. Omit it to start from now: the response is then an empty page carrying the feed's current position. Rejected with a `400` when malformed, or when older than the retention window. 
     # @option opts [Integer] :limit Page size. Out-of-range values are a 400, never a silent clamp. (default to 50)

data/lib/zernio-sdk/models/{conversation.rb → inbox_webhook_conversation_detail.rb}

@@ -14,7 +14,8 @@ require 'date'
 require 'time'
 
 module Zernio
-  class Conversation < ApiModelBase
+  # The conversation object included in conversation lifecycle webhook payloads (conversation.started, conversation.control_changed).
+  class InboxWebhookConversationDetail < ApiModelBase
     # Internal conversation ID
     attr_accessor :id
 
@@ -109,14 +110,14 @@ module Zernio
     # @param [Hash] attributes Model attributes in the form of hash
     def initialize(attributes = {})
       if (!attributes.is_a?(Hash))
-        fail ArgumentError, "The input argument (attributes) must be a hash in `Zernio::Conversation` initialize method"
+        fail ArgumentError, "The input argument (attributes) must be a hash in `Zernio::InboxWebhookConversationDetail` initialize method"
       end
 
       # check to see if the attribute exists and convert string to symbol for hash key
       acceptable_attribute_map = self.class.acceptable_attribute_map
       attributes = attributes.each_with_object({}) { |(k, v), h|
         if (!acceptable_attribute_map.key?(k.to_sym))
-          fail ArgumentError, "`#{k}` is not a valid attribute in `Zernio::Conversation`. Please check the name to make sure it's valid. List of attributes: " + acceptable_attribute_map.keys.inspect
+          fail ArgumentError, "`#{k}` is not a valid attribute in `Zernio::InboxWebhookConversationDetail`. Please check the name to make sure it's valid. List of attributes: " + acceptable_attribute_map.keys.inspect
         end
         h[k.to_sym] = v
       }

data/lib/zernio-sdk/models/webhook_payload_conversation_control_changed.rb

@@ -82,7 +82,7 @@ module Zernio
       {
         :'id' => :'String',
         :'event' => :'String',
-        :'conversation' => :'WebhookPayloadConversationStartedConversation',
+        :'conversation' => :'InboxWebhookConversationDetail',
         :'account' => :'InboxWebhookAccount',
         :'control' => :'WebhookPayloadConversationControlChangedControl',
         :'changed_at' => :'Time',

data/lib/zernio-sdk/models/webhook_payload_conversation_started.rb

@@ -80,7 +80,7 @@ module Zernio
       {
         :'id' => :'String',
         :'event' => :'String',
-        :'conversation' => :'WebhookPayloadConversationStartedConversation',
+        :'conversation' => :'InboxWebhookConversationDetail',
         :'account' => :'InboxWebhookAccount',
         :'started_at' => :'Time',
         :'timestamp' => :'Time'

data/lib/zernio-sdk/version.rb

@@ -11,5 +11,5 @@ Generator version: 7.19.0
 =end
 
 module Zernio
-  VERSION = '0.0.891'
+  VERSION = '0.0.893'
 end

data/lib/zernio-sdk.rb

@@ -238,7 +238,6 @@ require 'zernio-sdk/models/connect_whats_app_embedded_signup_request'
 require 'zernio-sdk/models/connected'
 require 'zernio-sdk/models/connected_account'
 require 'zernio-sdk/models/connected_app'
-require 'zernio-sdk/models/conversation'
 require 'zernio-sdk/models/conversion_action'
 require 'zernio-sdk/models/conversion_action_tag_snippets_inner'
 require 'zernio-sdk/models/conversion_destination'
@@ -914,6 +913,7 @@ require 'zernio-sdk/models/inbox_message_edit_attachment'
 require 'zernio-sdk/models/inbox_message_edit_history_entry'
 require 'zernio-sdk/models/inbox_webhook_account'
 require 'zernio-sdk/models/inbox_webhook_conversation'
+require 'zernio-sdk/models/inbox_webhook_conversation_detail'
 require 'zernio-sdk/models/inbox_webhook_message'
 require 'zernio-sdk/models/inbox_webhook_message_attachments_inner'
 require 'zernio-sdk/models/inbox_webhook_message_sender'
@@ -1828,7 +1828,6 @@ require 'zernio-sdk/models/webhook_payload_comment_post'
 require 'zernio-sdk/models/webhook_payload_conversation_control_changed'
 require 'zernio-sdk/models/webhook_payload_conversation_control_changed_control'
 require 'zernio-sdk/models/webhook_payload_conversation_started'
-require 'zernio-sdk/models/webhook_payload_conversation_started_conversation'
 require 'zernio-sdk/models/webhook_payload_external_post'
 require 'zernio-sdk/models/webhook_payload_lead'
 require 'zernio-sdk/models/webhook_payload_lead_account'

data/openapi.yaml

@@ -3599,6 +3599,32 @@ components:
             integrators join any inbox webhook back to the CRM Contact without
             needing to look at the sender, which matters for outgoing and
             delivery-status events whose sender is the business.
+    InboxWebhookConversationDetail:
+      type: object
+      description: The conversation object included in conversation lifecycle webhook payloads (conversation.started, conversation.control_changed).
+      required: [id, platform, platformConversationId, participantName, status]
+      properties:
+        id: { type: string, description: Internal conversation ID }
+        platform:
+          type: string
+          enum: [instagram, facebook, telegram, whatsapp, twitter, reddit, bluesky, sms, slack]
+        platformConversationId: { type: string }
+        participantId: { type: string, description: "Contact's platform identifier (IGSID, PSID, wa_id, etc.)" }
+        participantName: { type: string }
+        participantUsername: { type: string, description: Contact's handle when the platform exposes one }
+        participantPicture: { type: string }
+        status:
+          type: string
+          enum: [active, archived]
+        contactId:
+          type: string
+          description: |
+            Zernio CRM Contact ID for the participant, when one exists. Resolved by
+            joining `participantId` to the ContactChannel collection (same join
+            used by message.*, reaction.received, and call.* webhooks). Best-effort:
+            omitted when no channel matches or `participantId` is absent. Lets
+            integrators seed the CRM straight from `conversation.started` without
+            waiting for the first `message.*` event.
     InboxWebhookAccount:
       type: object
       description: The account context included in inbox webhook payloads.
@@ -4518,30 +4544,7 @@ components:
           type: string
           enum: [conversation.started]
         conversation:
-          type: object
-          required: [id, platform, platformConversationId, participantName, status]
-          properties:
-            id: { type: string, description: Internal conversation ID }
-            platform:
-              type: string
-              enum: [instagram, facebook, telegram, whatsapp, twitter, reddit, bluesky, sms, slack]
-            platformConversationId: { type: string }
-            participantId: { type: string, description: "Contact's platform identifier (IGSID, PSID, wa_id, etc.)" }
-            participantName: { type: string }
-            participantUsername: { type: string, description: Contact's handle when the platform exposes one }
-            participantPicture: { type: string }
-            status:
-              type: string
-              enum: [active, archived]
-            contactId:
-              type: string
-              description: |
-                Zernio CRM Contact ID for the participant, when one exists. Resolved by
-                joining `participantId` to the ContactChannel collection (same join
-                used by message.*, reaction.received, and call.* webhooks). Best-effort:
-                omitted when no channel matches or `participantId` is absent. Lets
-                integrators seed the CRM straight from `conversation.started` without
-                waiting for the first `message.*` event.
+          $ref: '#/components/schemas/InboxWebhookConversationDetail'
         account:
           $ref: '#/components/schemas/InboxWebhookAccount'
         startedAt:
@@ -4564,7 +4567,7 @@ components:
           type: string
           enum: [conversation.control_changed]
         conversation:
-          $ref: '#/components/schemas/WebhookPayloadConversationStarted/properties/conversation'
+          $ref: '#/components/schemas/InboxWebhookConversationDetail'
         account:
           $ref: '#/components/schemas/InboxWebhookAccount'
         control:
@@ -11778,13 +11781,17 @@ paths:
         1,600 connected accounts: about 1,599 per-account analytics calls an hour became
         about 205 delta calls an hour, a 7.8x reduction.
 
-        **Bootstrap once, then stay in sync.** Load your baseline from
-        `GET /v1/analytics`, which is the historical endpoint. This one is a rolling
-        7-day change log and cannot replay history. Then call this endpoint with NO
-        `cursor`: it answers with an empty `data` array plus the feed's current position
-        in `nextCursor`. Send that `nextCursor` back on the next call and you receive
-        everything written since. `nextCursor` is present on every response, empty pages
-        included, so you always have something to advance with.
+        **Bootstrap once, then stay in sync.** Take the cursor FIRST: call this endpoint
+        with NO `cursor` and it answers with an empty `data` array plus the feed's current
+        position in `nextCursor`. Then load your baseline from `GET /v1/analytics`, the
+        historical endpoint, because this one is a rolling 7-day change log and cannot
+        replay history. Then resume from the cursor you took before the baseline. Taking
+        the cursor afterwards instead drops every change that lands while the baseline is
+        loading: it is in neither the row you already read nor the feed you resume behind
+        it. The overlap this order creates is safe, because metrics are absolute values
+        rather than increments, so draining it leaves every post on its newest value.
+        `nextCursor` is present on every response, empty pages included, so you always
+        have something to advance with.
 
         **Ordering.** Entries come back oldest first, in the order the feed received
         them. That order is NOT `syncedAt`: `syncedAt` is stamped when an account's sync
@@ -11814,9 +11821,9 @@ paths:
 
         **Retention is 7 days.** Changes older than that leave the feed. A cursor older
         than 6 days is rejected with a `400` (a day of margin, because expiry is lazy).
-        Recover by re-bootstrapping from `GET /v1/analytics` and taking a fresh cursor
-        from a call to this endpoint with no `cursor`. A consumer that polls at least
-        daily never reaches this.
+        Recover the same way you bootstrapped: take a fresh cursor from a call to this
+        endpoint with no `cursor`, then re-load from `GET /v1/analytics`, then resume
+        from that cursor. A consumer that polls at least daily never reaches this.
 
         Pairs with the `analytics.synced` webhook, so changes can be read on notification
         instead of on a timer. That event carries no cursor of its own: keep using the

data/spec/api/analytics_api_spec.rb

@@ -56,7 +56,7 @@ describe 'AnalyticsApi' do
 
   # unit tests for get_analytics_delta
   # Analytics changed since a cursor
-  # Cursor feed of the analytics snapshots that CHANGED, across every account you can read, in one paginated stream. Built for integrations that would otherwise call `GET /v1/analytics` once per connected account. Each page carries changes from many accounts at once, so your call count scales with how much actually changed rather than with how many accounts you have. Measured against a fleet of roughly 1,600 connected accounts: about 1,599 per-account analytics calls an hour became about 205 delta calls an hour, a 7.8x reduction.  **Bootstrap once, then stay in sync.** Load your baseline from `GET /v1/analytics`, which is the historical endpoint. This one is a rolling 7-day change log and cannot replay history. Then call this endpoint with NO `cursor`: it answers with an empty `data` array plus the feed's current position in `nextCursor`. Send that `nextCursor` back on the next call and you receive everything written since. `nextCursor` is present on every response, empty pages included, so you always have something to advance with.  **Ordering.** Entries come back oldest first, in the order the feed received them. That order is NOT `syncedAt`: `syncedAt` is stamped when an account's sync cycle started, and a slow cycle writes its rows after a faster cycle that started later, so `syncedAt` can go backwards between consecutive entries. Do not sort, filter or resume on it. The cursor is the only stable position, and it is opaque: pass it back verbatim, and do not parse, construct or compare cursors.  **`hasMore: false` does not mean the feed ended.** This stream has no end and `nextCursor` is never null. `hasMore: true` means more changes are already waiting, so call again straight away. `hasMore: false` means you are caught up: keep the cursor and poll again on your normal interval.  **The newest changes settle before they are served.** The feed deliberately holds back its last few seconds of writes, so that a row can never become visible behind a cursor you have already advanced past. A read issued the instant an `analytics.synced` webhook lands will therefore often return an empty page for that account. Do not read an empty page as \"nothing changed\": poll again with the SAME cursor you last used rather than advancing.  **Repeats inside one instant.** A sync cycle occasionally records the same post twice at the same feed position. When that happens the feed delivers one of those rows, not both. Measured over a day of production traffic, about 1.3% of rows fall in such a group and 99.4% of those groups are identical rows, so this is far more often deduplication than loss. Metrics are absolute values rather than increments, so a later entry for the same post supersedes an earlier one.  **Retention is 7 days.** Changes older than that leave the feed. A cursor older than 6 days is rejected with a `400` (a day of margin, because expiry is lazy). Recover by re-bootstrapping from `GET /v1/analytics` and taking a fresh cursor from a call to this endpoint with no `cursor`. A consumer that polls at least daily never reaches this.  Pairs with the `analytics.synced` webhook, so changes can be read on notification instead of on a timer. That event carries no cursor of its own: keep using the `nextCursor` this endpoint gave you.  Requires the same analytics access as `GET /v1/analytics`, and shares the stricter per-second rate-limit window applied to analytics endpoints. 
+  # Cursor feed of the analytics snapshots that CHANGED, across every account you can read, in one paginated stream. Built for integrations that would otherwise call `GET /v1/analytics` once per connected account. Each page carries changes from many accounts at once, so your call count scales with how much actually changed rather than with how many accounts you have. Measured against a fleet of roughly 1,600 connected accounts: about 1,599 per-account analytics calls an hour became about 205 delta calls an hour, a 7.8x reduction.  **Bootstrap once, then stay in sync.** Take the cursor FIRST: call this endpoint with NO `cursor` and it answers with an empty `data` array plus the feed's current position in `nextCursor`. Then load your baseline from `GET /v1/analytics`, the historical endpoint, because this one is a rolling 7-day change log and cannot replay history. Then resume from the cursor you took before the baseline. Taking the cursor afterwards instead drops every change that lands while the baseline is loading: it is in neither the row you already read nor the feed you resume behind it. The overlap this order creates is safe, because metrics are absolute values rather than increments, so draining it leaves every post on its newest value. `nextCursor` is present on every response, empty pages included, so you always have something to advance with.  **Ordering.** Entries come back oldest first, in the order the feed received them. That order is NOT `syncedAt`: `syncedAt` is stamped when an account's sync cycle started, and a slow cycle writes its rows after a faster cycle that started later, so `syncedAt` can go backwards between consecutive entries. Do not sort, filter or resume on it. The cursor is the only stable position, and it is opaque: pass it back verbatim, and do not parse, construct or compare cursors.  **`hasMore: false` does not mean the feed ended.** This stream has no end and `nextCursor` is never null. `hasMore: true` means more changes are already waiting, so call again straight away. `hasMore: false` means you are caught up: keep the cursor and poll again on your normal interval.  **The newest changes settle before they are served.** The feed deliberately holds back its last few seconds of writes, so that a row can never become visible behind a cursor you have already advanced past. A read issued the instant an `analytics.synced` webhook lands will therefore often return an empty page for that account. Do not read an empty page as \"nothing changed\": poll again with the SAME cursor you last used rather than advancing.  **Repeats inside one instant.** A sync cycle occasionally records the same post twice at the same feed position. When that happens the feed delivers one of those rows, not both. Measured over a day of production traffic, about 1.3% of rows fall in such a group and 99.4% of those groups are identical rows, so this is far more often deduplication than loss. Metrics are absolute values rather than increments, so a later entry for the same post supersedes an earlier one.  **Retention is 7 days.** Changes older than that leave the feed. A cursor older than 6 days is rejected with a `400` (a day of margin, because expiry is lazy). Recover the same way you bootstrapped: take a fresh cursor from a call to this endpoint with no `cursor`, then re-load from `GET /v1/analytics`, then resume from that cursor. A consumer that polls at least daily never reaches this.  Pairs with the `analytics.synced` webhook, so changes can be read on notification instead of on a timer. That event carries no cursor of its own: keep using the `nextCursor` this endpoint gave you.  Requires the same analytics access as `GET /v1/analytics`, and shares the stricter per-second rate-limit window applied to analytics endpoints. 
   # @param [Hash] opts the optional parameters
   # @option opts [String] :cursor Opaque cursor from a previous response's `nextCursor`. Omit it to start from now: the response is then an empty page carrying the feed's current position. Rejected with a `400` when malformed, or when older than the retention window. 
   # @option opts [Integer] :limit Page size. Out-of-range values are a 400, never a silent clamp.

data/spec/models/{conversation_spec.rb → inbox_webhook_conversation_detail_spec.rb}

@@ -14,16 +14,16 @@ require 'spec_helper'
 require 'json'
 require 'date'
 
-# Unit tests for Zernio::Conversation
+# Unit tests for Zernio::InboxWebhookConversationDetail
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe Zernio::Conversation do
-  #let(:instance) { Zernio::Conversation.new }
+describe Zernio::InboxWebhookConversationDetail do
+  #let(:instance) { Zernio::InboxWebhookConversationDetail.new }
 
-  describe 'test an instance of Conversation' do
-    it 'should create an instance of Conversation' do
+  describe 'test an instance of InboxWebhookConversationDetail' do
+    it 'should create an instance of InboxWebhookConversationDetail' do
       # uncomment below to test the instance creation
-      #expect(instance).to be_instance_of(Zernio::Conversation)
+      #expect(instance).to be_instance_of(Zernio::InboxWebhookConversationDetail)
     end
   end
 

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: late-sdk
 version: !ruby/object:Gem::Version
-  version: 0.0.891
+  version: 0.0.893
 platform: ruby
 authors:
 - OpenAPI-Generator
@@ -309,7 +309,6 @@ files:
 - docs/ConnectedApp.md
 - docs/ConnectedAppsApi.md
 - docs/ContactsApi.md
-- docs/Conversation.md
 - docs/ConversionAction.md
 - docs/ConversionActionTagSnippetsInner.md
 - docs/ConversionDestination.md
@@ -997,6 +996,7 @@ files:
 - docs/InboxMessageEditHistoryEntry.md
 - docs/InboxWebhookAccount.md
 - docs/InboxWebhookConversation.md
+- docs/InboxWebhookConversationDetail.md
 - docs/InboxWebhookMessage.md
 - docs/InboxWebhookMessageAttachmentsInner.md
 - docs/InboxWebhookMessageSender.md
@@ -1938,7 +1938,6 @@ files:
 - docs/WebhookPayloadConversationControlChanged.md
 - docs/WebhookPayloadConversationControlChangedControl.md
 - docs/WebhookPayloadConversationStarted.md
-- docs/WebhookPayloadConversationStartedConversation.md
 - docs/WebhookPayloadExternalPost.md
 - docs/WebhookPayloadLead.md
 - docs/WebhookPayloadLeadAccount.md
@@ -2360,7 +2359,6 @@ files:
 - lib/zernio-sdk/models/connected.rb
 - lib/zernio-sdk/models/connected_account.rb
 - lib/zernio-sdk/models/connected_app.rb
-- lib/zernio-sdk/models/conversation.rb
 - lib/zernio-sdk/models/conversion_action.rb
 - lib/zernio-sdk/models/conversion_action_tag_snippets_inner.rb
 - lib/zernio-sdk/models/conversion_destination.rb
@@ -3036,6 +3034,7 @@ files:
 - lib/zernio-sdk/models/inbox_message_edit_history_entry.rb
 - lib/zernio-sdk/models/inbox_webhook_account.rb
 - lib/zernio-sdk/models/inbox_webhook_conversation.rb
+- lib/zernio-sdk/models/inbox_webhook_conversation_detail.rb
 - lib/zernio-sdk/models/inbox_webhook_message.rb
 - lib/zernio-sdk/models/inbox_webhook_message_attachments_inner.rb
 - lib/zernio-sdk/models/inbox_webhook_message_sender.rb
@@ -3950,7 +3949,6 @@ files:
 - lib/zernio-sdk/models/webhook_payload_conversation_control_changed.rb
 - lib/zernio-sdk/models/webhook_payload_conversation_control_changed_control.rb
 - lib/zernio-sdk/models/webhook_payload_conversation_started.rb
-- lib/zernio-sdk/models/webhook_payload_conversation_started_conversation.rb
 - lib/zernio-sdk/models/webhook_payload_external_post.rb
 - lib/zernio-sdk/models/webhook_payload_lead.rb
 - lib/zernio-sdk/models/webhook_payload_lead_account.rb
@@ -4358,7 +4356,6 @@ files:
 - spec/models/connected_account_spec.rb
 - spec/models/connected_app_spec.rb
 - spec/models/connected_spec.rb
-- spec/models/conversation_spec.rb
 - spec/models/conversion_action_spec.rb
 - spec/models/conversion_action_tag_snippets_inner_spec.rb
 - spec/models/conversion_destination_spec.rb
@@ -5033,6 +5030,7 @@ files:
 - spec/models/inbox_message_edit_attachment_spec.rb
 - spec/models/inbox_message_edit_history_entry_spec.rb
 - spec/models/inbox_webhook_account_spec.rb
+- spec/models/inbox_webhook_conversation_detail_spec.rb
 - spec/models/inbox_webhook_conversation_spec.rb
 - spec/models/inbox_webhook_message_attachments_inner_spec.rb
 - spec/models/inbox_webhook_message_sender_instagram_profile_spec.rb
@@ -5946,7 +5944,6 @@ files:
 - spec/models/webhook_payload_comment_spec.rb
 - spec/models/webhook_payload_conversation_control_changed_control_spec.rb
 - spec/models/webhook_payload_conversation_control_changed_spec.rb
-- spec/models/webhook_payload_conversation_started_conversation_spec.rb
 - spec/models/webhook_payload_conversation_started_spec.rb
 - spec/models/webhook_payload_external_post_spec.rb
 - spec/models/webhook_payload_lead_account_spec.rb
@@ -6067,7 +6064,7 @@ files:
 - spec/models/you_tube_video_retention_response_retention_curve_inner_spec.rb
 - spec/models/you_tube_video_retention_response_spec.rb
 - spec/spec_helper.rb
-- zernio-sdk-0.0.891.gem
+- zernio-sdk-0.0.893.gem
 - zernio-sdk.gemspec
 homepage: https://openapi-generator.tech
 licenses:
@@ -6941,7 +6938,6 @@ test_files:
 - spec/models/list_inbox_conversation_analytics200_response_spec.rb
 - spec/models/targeting_spec_excluded_locations_places_inner_spec.rb
 - spec/models/list_high_demand_periods200_response_spec.rb
-- spec/models/conversation_spec.rb
 - spec/models/create_voice_call200_response_spec.rb
 - spec/models/create_standalone_ad_request_dynamic_creative_spec.rb
 - spec/models/inbox_webhook_message_sender_instagram_profile_spec.rb
@@ -7751,6 +7747,7 @@ test_files:
 - spec/models/get_whats_app_sdk_config200_response_spec.rb
 - spec/models/whats_app_carousel_component_cards_inner_spec.rb
 - spec/models/get_inbox_conversation_messages200_response_messages_inner_attachments_inner_spec.rb
+- spec/models/inbox_webhook_conversation_detail_spec.rb
 - spec/models/validate_post_request_spec.rb
 - spec/models/list_users200_response_spec.rb
 - spec/models/ad_keyword_metrics_spec.rb
@@ -8023,7 +8020,6 @@ test_files:
 - spec/models/webhook_payload_call_received_spec.rb
 - spec/models/update_discord_settings200_response_account_spec.rb
 - spec/models/get_whats_app_business_profile200_response_spec.rb
-- spec/models/webhook_payload_conversation_started_conversation_spec.rb
 - spec/models/get_inbox_conversation_messages200_response_spec.rb
 - spec/models/get_google_business_reviews200_response_spec.rb
 - spec/models/list_whats_app_flow_versions200_response_spec.rb

data/docs/WebhookPayloadConversationStartedConversation.md

@@ -1,34 +0,0 @@
-# Zernio::WebhookPayloadConversationStartedConversation
-
-## Properties
-
-| Name | Type | Description | Notes |
-| ---- | ---- | ----------- | ----- |
-| **id** | **String** | Internal conversation ID |  |
-| **platform** | **String** |  |  |
-| **platform_conversation_id** | **String** |  |  |
-| **participant_id** | **String** | Contact's platform identifier (IGSID, PSID, wa_id, etc.) | [optional] |
-| **participant_name** | **String** |  |  |
-| **participant_username** | **String** | Contact's handle when the platform exposes one | [optional] |
-| **participant_picture** | **String** |  | [optional] |
-| **status** | **String** |  |  |
-| **contact_id** | **String** | Zernio CRM Contact ID for the participant, when one exists. Resolved by joining `participantId` to the ContactChannel collection (same join used by message.*, reaction.received, and call.* webhooks). Best-effort: omitted when no channel matches or `participantId` is absent. Lets integrators seed the CRM straight from `conversation.started` without waiting for the first `message.*` event.  | [optional] |
-
-## Example
-
-```ruby
-require 'zernio-sdk'
-
-instance = Zernio::WebhookPayloadConversationStartedConversation.new(
-  id: null,
-  platform: null,
-  platform_conversation_id: null,
-  participant_id: null,
-  participant_name: null,
-  participant_username: null,
-  participant_picture: null,
-  status: null,
-  contact_id: null
-)
-```
-

data/lib/zernio-sdk/models/webhook_payload_conversation_started_conversation.rb

@@ -1,334 +0,0 @@
-=begin
-#Zernio API
-
-#API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema). 
-
-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 'date'
-require 'time'
-
-module Zernio
-  class WebhookPayloadConversationStartedConversation < ApiModelBase
-    # Internal conversation ID
-    attr_accessor :id
-
-    attr_accessor :platform
-
-    attr_accessor :platform_conversation_id
-
-    # Contact's platform identifier (IGSID, PSID, wa_id, etc.)
-    attr_accessor :participant_id
-
-    attr_accessor :participant_name
-
-    # Contact's handle when the platform exposes one
-    attr_accessor :participant_username
-
-    attr_accessor :participant_picture
-
-    attr_accessor :status
-
-    # Zernio CRM Contact ID for the participant, when one exists. Resolved by joining `participantId` to the ContactChannel collection (same join used by message.*, reaction.received, and call.* webhooks). Best-effort: omitted when no channel matches or `participantId` is absent. Lets integrators seed the CRM straight from `conversation.started` without waiting for the first `message.*` event. 
-    attr_accessor :contact_id
-
-    class EnumAttributeValidator
-      attr_reader :datatype
-      attr_reader :allowable_values
-
-      def initialize(datatype, allowable_values)
-        @allowable_values = allowable_values.map do |value|
-          case datatype.to_s
-          when /Integer/i
-            value.to_i
-          when /Float/i
-            value.to_f
-          else
-            value
-          end
-        end
-      end
-
-      def valid?(value)
-        !value || allowable_values.include?(value)
-      end
-    end
-
-    # Attribute mapping from ruby-style variable name to JSON key.
-    def self.attribute_map
-      {
-        :'id' => :'id',
-        :'platform' => :'platform',
-        :'platform_conversation_id' => :'platformConversationId',
-        :'participant_id' => :'participantId',
-        :'participant_name' => :'participantName',
-        :'participant_username' => :'participantUsername',
-        :'participant_picture' => :'participantPicture',
-        :'status' => :'status',
-        :'contact_id' => :'contactId'
-      }
-    end
-
-    # Returns attribute mapping this model knows about
-    def self.acceptable_attribute_map
-      attribute_map
-    end
-
-    # Returns all the JSON keys this model knows about
-    def self.acceptable_attributes
-      acceptable_attribute_map.values
-    end
-
-    # Attribute type mapping.
-    def self.openapi_types
-      {
-        :'id' => :'String',
-        :'platform' => :'String',
-        :'platform_conversation_id' => :'String',
-        :'participant_id' => :'String',
-        :'participant_name' => :'String',
-        :'participant_username' => :'String',
-        :'participant_picture' => :'String',
-        :'status' => :'String',
-        :'contact_id' => :'String'
-      }
-    end
-
-    # List of attributes with nullable: true
-    def self.openapi_nullable
-      Set.new([
-      ])
-    end
-
-    # Initializes the object
-    # @param [Hash] attributes Model attributes in the form of hash
-    def initialize(attributes = {})
-      if (!attributes.is_a?(Hash))
-        fail ArgumentError, "The input argument (attributes) must be a hash in `Zernio::WebhookPayloadConversationStartedConversation` initialize method"
-      end
-
-      # check to see if the attribute exists and convert string to symbol for hash key
-      acceptable_attribute_map = self.class.acceptable_attribute_map
-      attributes = attributes.each_with_object({}) { |(k, v), h|
-        if (!acceptable_attribute_map.key?(k.to_sym))
-          fail ArgumentError, "`#{k}` is not a valid attribute in `Zernio::WebhookPayloadConversationStartedConversation`. Please check the name to make sure it's valid. List of attributes: " + acceptable_attribute_map.keys.inspect
-        end
-        h[k.to_sym] = v
-      }
-
-      if attributes.key?(:'id')
-        self.id = attributes[:'id']
-      else
-        self.id = nil
-      end
-
-      if attributes.key?(:'platform')
-        self.platform = attributes[:'platform']
-      else
-        self.platform = nil
-      end
-
-      if attributes.key?(:'platform_conversation_id')
-        self.platform_conversation_id = attributes[:'platform_conversation_id']
-      else
-        self.platform_conversation_id = nil
-      end
-
-      if attributes.key?(:'participant_id')
-        self.participant_id = attributes[:'participant_id']
-      end
-
-      if attributes.key?(:'participant_name')
-        self.participant_name = attributes[:'participant_name']
-      else
-        self.participant_name = nil
-      end
-
-      if attributes.key?(:'participant_username')
-        self.participant_username = attributes[:'participant_username']
-      end
-
-      if attributes.key?(:'participant_picture')
-        self.participant_picture = attributes[:'participant_picture']
-      end
-
-      if attributes.key?(:'status')
-        self.status = attributes[:'status']
-      else
-        self.status = nil
-      end
-
-      if attributes.key?(:'contact_id')
-        self.contact_id = attributes[:'contact_id']
-      end
-    end
-
-    # Show invalid properties with the reasons. Usually used together with valid?
-    # @return Array for valid properties with the reasons
-    def list_invalid_properties
-      warn '[DEPRECATED] the `list_invalid_properties` method is obsolete'
-      invalid_properties = Array.new
-      if @id.nil?
-        invalid_properties.push('invalid value for "id", id cannot be nil.')
-      end
-
-      if @platform.nil?
-        invalid_properties.push('invalid value for "platform", platform cannot be nil.')
-      end
-
-      if @platform_conversation_id.nil?
-        invalid_properties.push('invalid value for "platform_conversation_id", platform_conversation_id cannot be nil.')
-      end
-
-      if @participant_name.nil?
-        invalid_properties.push('invalid value for "participant_name", participant_name cannot be nil.')
-      end
-
-      if @status.nil?
-        invalid_properties.push('invalid value for "status", status cannot be nil.')
-      end
-
-      invalid_properties
-    end
-
-    # Check to see if the all the properties in the model are valid
-    # @return true if the model is valid
-    def valid?
-      warn '[DEPRECATED] the `valid?` method is obsolete'
-      return false if @id.nil?
-      return false if @platform.nil?
-      platform_validator = EnumAttributeValidator.new('String', ["instagram", "facebook", "telegram", "whatsapp", "twitter", "reddit", "bluesky", "sms", "slack"])
-      return false unless platform_validator.valid?(@platform)
-      return false if @platform_conversation_id.nil?
-      return false if @participant_name.nil?
-      return false if @status.nil?
-      status_validator = EnumAttributeValidator.new('String', ["active", "archived"])
-      return false unless status_validator.valid?(@status)
-      true
-    end
-
-    # Custom attribute writer method with validation
-    # @param [Object] id Value to be assigned
-    def id=(id)
-      if id.nil?
-        fail ArgumentError, 'id cannot be nil'
-      end
-
-      @id = id
-    end
-
-    # Custom attribute writer method checking allowed values (enum).
-    # @param [Object] platform Object to be assigned
-    def platform=(platform)
-      validator = EnumAttributeValidator.new('String', ["instagram", "facebook", "telegram", "whatsapp", "twitter", "reddit", "bluesky", "sms", "slack"])
-      unless validator.valid?(platform)
-        fail ArgumentError, "invalid value for \"platform\", must be one of #{validator.allowable_values}."
-      end
-      @platform = platform
-    end
-
-    # Custom attribute writer method with validation
-    # @param [Object] platform_conversation_id Value to be assigned
-    def platform_conversation_id=(platform_conversation_id)
-      if platform_conversation_id.nil?
-        fail ArgumentError, 'platform_conversation_id cannot be nil'
-      end
-
-      @platform_conversation_id = platform_conversation_id
-    end
-
-    # Custom attribute writer method with validation
-    # @param [Object] participant_name Value to be assigned
-    def participant_name=(participant_name)
-      if participant_name.nil?
-        fail ArgumentError, 'participant_name cannot be nil'
-      end
-
-      @participant_name = participant_name
-    end
-
-    # Custom attribute writer method checking allowed values (enum).
-    # @param [Object] status Object to be assigned
-    def status=(status)
-      validator = EnumAttributeValidator.new('String', ["active", "archived"])
-      unless validator.valid?(status)
-        fail ArgumentError, "invalid value for \"status\", must be one of #{validator.allowable_values}."
-      end
-      @status = status
-    end
-
-    # Checks equality by comparing each attribute.
-    # @param [Object] Object to be compared
-    def ==(o)
-      return true if self.equal?(o)
-      self.class == o.class &&
-          id == o.id &&
-          platform == o.platform &&
-          platform_conversation_id == o.platform_conversation_id &&
-          participant_id == o.participant_id &&
-          participant_name == o.participant_name &&
-          participant_username == o.participant_username &&
-          participant_picture == o.participant_picture &&
-          status == o.status &&
-          contact_id == o.contact_id
-    end
-
-    # @see the `==` method
-    # @param [Object] Object to be compared
-    def eql?(o)
-      self == o
-    end
-
-    # Calculates hash code according to all attributes.
-    # @return [Integer] Hash code
-    def hash
-      [id, platform, platform_conversation_id, participant_id, participant_name, participant_username, participant_picture, status, contact_id].hash
-    end
-
-    # Builds the object from hash
-    # @param [Hash] attributes Model attributes in the form of hash
-    # @return [Object] Returns the model itself
-    def self.build_from_hash(attributes)
-      return nil unless attributes.is_a?(Hash)
-      attributes = attributes.transform_keys(&:to_sym)
-      transformed_hash = {}
-      openapi_types.each_pair do |key, type|
-        if attributes.key?(attribute_map[key]) && attributes[attribute_map[key]].nil?
-          transformed_hash["#{key}"] = nil
-        elsif type =~ /\AArray<(.*)>/i
-          # check to ensure the input is an array given that the attribute
-          # is documented as an array but the input is not
-          if attributes[attribute_map[key]].is_a?(Array)
-            transformed_hash["#{key}"] = attributes[attribute_map[key]].map { |v| _deserialize($1, v) }
-          end
-        elsif !attributes[attribute_map[key]].nil?
-          transformed_hash["#{key}"] = _deserialize(type, attributes[attribute_map[key]])
-        end
-      end
-      new(transformed_hash)
-    end
-
-    # Returns the object in the form of hash
-    # @return [Hash] Returns the object in the form of hash
-    def to_hash
-      hash = {}
-      self.class.attribute_map.each_pair do |attr, param|
-        value = self.send(attr)
-        if value.nil?
-          is_nullable = self.class.openapi_nullable.include?(attr)
-          next if !is_nullable || (is_nullable && !instance_variable_defined?(:"@#{attr}"))
-        end
-
-        hash[param] = _to_hash(value)
-      end
-      hash
-    end
-
-  end
-
-end

data/spec/models/webhook_payload_conversation_started_conversation_spec.rb

@@ -1,92 +0,0 @@
-=begin
-#Zernio API
-
-#API reference for Zernio. Authenticate with a Bearer API key. Base URL: https://zernio.com/api  Versioning and deprecation: all endpoints are versioned in the URL path (current version: /v1). Breaking changes only ship in a new path version; existing versions keep working. Deprecated operations are marked 'deprecated: true' in this spec and announced in the changelog (https://zernio.com/changelog) before removal.  Errors: every 4xx/5xx response is application/json with a machine-readable 'code' and a human-readable 'error' message (see the ErrorResponse schema). 
-
-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::WebhookPayloadConversationStartedConversation
-# Automatically generated by openapi-generator (https://openapi-generator.tech)
-# Please update as you see appropriate
-describe Zernio::WebhookPayloadConversationStartedConversation do
-  #let(:instance) { Zernio::WebhookPayloadConversationStartedConversation.new }
-
-  describe 'test an instance of WebhookPayloadConversationStartedConversation' do
-    it 'should create an instance of WebhookPayloadConversationStartedConversation' do
-      # uncomment below to test the instance creation
-      #expect(instance).to be_instance_of(Zernio::WebhookPayloadConversationStartedConversation)
-    end
-  end
-
-  describe 'test attribute "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 "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', ["instagram", "facebook", "telegram", "whatsapp", "twitter", "reddit", "bluesky", "sms", "slack"])
-      # validator.allowable_values.each do |value|
-      #   expect { instance.platform = value }.not_to raise_error
-      # end
-    end
-  end
-
-  describe 'test attribute "platform_conversation_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 "participant_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 "participant_name"' do
-    it 'should work' do
-      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
-    end
-  end
-
-  describe 'test attribute "participant_username"' do
-    it 'should work' do
-      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
-    end
-  end
-
-  describe 'test attribute "participant_picture"' do
-    it 'should work' do
-      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
-    end
-  end
-
-  describe 'test attribute "status"' 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', ["active", "archived"])
-      # validator.allowable_values.each do |value|
-      #   expect { instance.status = value }.not_to raise_error
-      # end
-    end
-  end
-
-  describe 'test attribute "contact_id"' do
-    it 'should work' do
-      # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
-    end
-  end
-
-end