late-sdk 0.0.815 → 0.0.817

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 041bcf4624710e18b46bafa4fffc72ca5a6abbca5c7f558b6eba76aff7478d4c
-  data.tar.gz: 65ae0ed2304e4b20029879dc14e6ace1173fe34d51994d51977e59cd2b031f90
+  metadata.gz: d29b0cbbf50db66d905333a2e8fab599ca23fecd7969776b71fb4d807438b96f
+  data.tar.gz: 438af5ae30990214dd632d4755009c50bc48515c6a9dbb67ded13fbfc378d0f0
 SHA512:
-  metadata.gz: d81c5be5ef439bcf522d41566a5d16e1656a8d0ec15b2289bb125f1ce89a44a7aac9e00ae3ffa5e649cfe241ad43b5ff80ed478cfc06269e3aa6112d6a1a9e6a
-  data.tar.gz: 73b2bbca6f986fbd45c2dc3fda4071c5563357e1185f6f654b5b5c0d7888d10b7fa23f30bed63b8e37090bc11c7d46a1fc985d61aeefa76fee73000b53696d8f
+  metadata.gz: 0bb4b19f6b93a0ba4bdb64c50fa4b1dc5492abb6b34053eb8bd84a15ec1645ded030723a811d066825d7f01213bbbabc8909c29040f586770235d4e69055c71c
+  data.tar.gz: c51f482669a348335381d23a6a1d995359a208959bd0e35c978936201fa22cf6d3492ed771869cacce6b2c409e512e98c9e47a530ed2716756668d0a6e7bdda6

data/docs/ConnectApi.md

@@ -1279,7 +1279,7 @@ end
 
 Get pending OAuth data
 
-Fetch pending OAuth data for headless mode using the pendingDataToken from the redirect URL.  **Scope**: This endpoint is used for LinkedIn organizations, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook, Google Business and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).  Token is one-time use and expires after 10 minutes. No authentication required. 
+Fetch pending OAuth data for headless mode using the pendingDataToken from the redirect URL.  **Scope**: This endpoint is used for LinkedIn organizations, Google Business locations, Slack channels, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).  Reading the token does not consume it, so this fetch is repeatable until the token expires 1 hour after issuance. Completing the platform selection deletes the pending record, so the token stops working from then on. No authentication required. 
 
 ### Examples
 

data/docs/WebhooksApi.md

@@ -304,7 +304,7 @@ This endpoint does not need any parameter.
 
 Redeliver a webhook event
 
-Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 500. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
+Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 422. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
 
 ### Examples
 

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

@@ -1244,7 +1244,7 @@ module Zernio
     end
 
     # Get pending OAuth data
-    # Fetch pending OAuth data for headless mode using the pendingDataToken from the redirect URL.  **Scope**: This endpoint is used for LinkedIn organizations, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook, Google Business and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).  Token is one-time use and expires after 10 minutes. No authentication required. 
+    # Fetch pending OAuth data for headless mode using the pendingDataToken from the redirect URL.  **Scope**: This endpoint is used for LinkedIn organizations, Google Business locations, Slack channels, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).  Reading the token does not consume it, so this fetch is repeatable until the token expires 1 hour after issuance. Completing the platform selection deletes the pending record, so the token stops working from then on. No authentication required. 
     # @param token [String] The pending data token from the OAuth redirect URL (pendingDataToken parameter)
     # @param [Hash] opts the optional parameters
     # @return [GetPendingOAuthData200Response]
@@ -1254,7 +1254,7 @@ module Zernio
     end
 
     # Get pending OAuth data
-    # Fetch pending OAuth data for headless mode using the pendingDataToken from the redirect URL.  **Scope**: This endpoint is used for LinkedIn organizations, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook, Google Business and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).  Token is one-time use and expires after 10 minutes. No authentication required. 
+    # Fetch pending OAuth data for headless mode using the pendingDataToken from the redirect URL.  **Scope**: This endpoint is used for LinkedIn organizations, Google Business locations, Slack channels, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).  Reading the token does not consume it, so this fetch is repeatable until the token expires 1 hour after issuance. Completing the platform selection deletes the pending record, so the token stops working from then on. No authentication required. 
     # @param token [String] The pending data token from the OAuth redirect URL (pendingDataToken parameter)
     # @param [Hash] opts the optional parameters
     # @return [Array<(GetPendingOAuthData200Response, Integer, Hash)>] GetPendingOAuthData200Response data, response status code and response headers

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

@@ -333,7 +333,7 @@ module Zernio
     end
 
     # Redeliver a webhook event
-    # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 500. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
+    # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 422. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
     # @param redeliver_webhook_event_request [RedeliverWebhookEventRequest] 
     # @param [Hash] opts the optional parameters
     # @return [UnpublishPost200Response]
@@ -343,7 +343,7 @@ module Zernio
     end
 
     # Redeliver a webhook event
-    # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 500. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
+    # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 422. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
     # @param redeliver_webhook_event_request [RedeliverWebhookEventRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(UnpublishPost200Response, Integer, Hash)>] UnpublishPost200Response data, response status code and response headers

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

@@ -14,7 +14,7 @@ require 'date'
 require 'time'
 
 module Zernio
-  # Replace or patch the ad's creative. Meta, TikTok, and LinkedIn.  - **Meta**: patch-style. Pass any subset — fields you omit are preserved from the   live creative, including media (`image_hash`/`video_id` are reused, no re-upload)   and `url_tags`. Sending the full set (`headline`, `body`, `callToAction`,   `linkUrl`, `imageUrl`) rebuilds the creative from scratch instead. Partial   patching reads the live `object_story_spec`, which Meta strips on SHARE /   page-post / dark / asset_feed creatives — those return 422 asking for the full   set. A `videoUrl`/`videoId` on an image creative is a type change and also   needs the full set. `existingCreativeId` repoints the ad at a creative from   GET /v1/ads/creatives and ignores every other field. Meta creatives are   immutable, so any change creates a new creative and repoints the ad; the old   creative is retained on the ad account for historical reporting. - **TikTok**: patch-style. Pass any subset; `headline` is ignored (TikTok creatives   have no headline slot). `body` becomes the in-feed `ad_text`; `linkUrl` becomes   `landing_page_url`; `videoUrl` triggers a fresh upload. `description`, `videoId`   and `existingCreativeId` are Meta-only and return 400. - **LinkedIn**: uploads new media (image via `imageUrl` or video via `videoUrl`),   creates a new inline media creative on the same campaign, and pauses the old   creative (best-effort). The old creative is retained for historical reporting.   `videoId` and `existingCreativeId` are Meta-only and return 400. 
+  # Replace or patch the ad's creative. Meta, TikTok, and LinkedIn.  - **Meta**: patch-style. Pass any subset — fields you omit are preserved from the   live creative, including media (`image_hash`/`video_id` are reused, no re-upload)   and `url_tags`. Sending the full set (`headline`, `body`, `callToAction`,   `linkUrl`, `imageUrl`) rebuilds the creative from scratch instead. Partial   patching reads the live `object_story_spec`, which Meta strips on SHARE /   page-post / dark / asset_feed creatives — those return 422 asking for the full   set. A `videoUrl`/`videoId` on an image creative is a type change and also   needs the full set. `existingCreativeId` repoints the ad at a creative from   GET /v1/ads/creatives and ignores every other field. Meta creatives are   immutable, so any change creates a new creative and repoints the ad; the old   creative is retained on the ad account for historical reporting. - **TikTok**: patch-style. Pass any subset; `headline` is ignored (TikTok creatives   have no headline slot). `body` becomes the in-feed `ad_text`; `linkUrl` becomes   `landing_page_url`; `videoUrl` triggers a fresh upload. `description`, `videoId`   and `existingCreativeId` are Meta-only and return 400. - **LinkedIn**: requires new media (image via `imageUrl` or video via `videoUrl`);   a text-only creative update returns 400. Uploads the media, creates a new inline   media creative on the same campaign, and pauses the old creative (best-effort).   The old creative is retained for historical reporting. `videoId` and   `existingCreativeId` are Meta-only and return 400. 
   class UpdateAdRequestCreative < ApiModelBase
     # Meta and LinkedIn (TikTok has no headline slot)
     attr_accessor :headline

data/lib/zernio-sdk/version.rb

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

data/openapi.yaml

@@ -20508,9 +20508,9 @@ paths:
       description: |
         Fetch pending OAuth data for headless mode using the pendingDataToken from the redirect URL.
 
-        **Scope**: This endpoint is used for LinkedIn organizations, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook, Google Business and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).
+        **Scope**: This endpoint is used for LinkedIn organizations, Google Business locations, Slack channels, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).
 
-        Token is one-time use and expires after 10 minutes. No authentication required.
+        Reading the token does not consume it, so this fetch is repeatable until the token expires 1 hour after issuance. Completing the platform selection deletes the pending record, so the token stops working from then on. No authentication required.
       parameters:
         - name: token
           in: query
@@ -25697,7 +25697,7 @@ paths:
         emitted, not the current state of the resource.
 
         Only deliveries inside the 30-day log retention window can be replayed; past that
-        the payload is gone and the request fails with a 500. Replays run the same
+        the payload is gone and the request fails with a 422. Replays run the same
         resource-group checks as live delivery, against both the key's groups and the
         subscription's `disabledResourceGroups`.
       security:
@@ -25736,10 +25736,11 @@ paths:
               example:
                 success: true
                 message: "Webhook re-delivered"
-        '400': { description: 'webhookId or eventId missing or empty' }
+        '400': { description: 'webhookId or eventId missing or empty, or the subscription has no URL configured' }
         '401': { $ref: '#/components/responses/Unauthorized' }
         '403': { $ref: '#/components/responses/ResourceGroupForbidden' }
-        '500': { description: 'Webhook no longer exists, has no URL configured, or the original payload is outside the 30-day retention window' }
+        '404': { description: 'Webhook subscription not found' }
+        '422': { description: 'Original payload not replayable: no delivery matches this event inside the 30-day retention window, or the stored payload is truncated or not valid JSON' }
         '502':
           description: |
             Re-delivery was attempted but your endpoint errored again. The attempt is still
@@ -41662,10 +41663,11 @@ paths:
                       have no headline slot). `body` becomes the in-feed `ad_text`; `linkUrl` becomes
                       `landing_page_url`; `videoUrl` triggers a fresh upload. `description`, `videoId`
                       and `existingCreativeId` are Meta-only and return 400.
-                    - **LinkedIn**: uploads new media (image via `imageUrl` or video via `videoUrl`),
-                      creates a new inline media creative on the same campaign, and pauses the old
-                      creative (best-effort). The old creative is retained for historical reporting.
-                      `videoId` and `existingCreativeId` are Meta-only and return 400.
+                    - **LinkedIn**: requires new media (image via `imageUrl` or video via `videoUrl`);
+                      a text-only creative update returns 400. Uploads the media, creates a new inline
+                      media creative on the same campaign, and pauses the old creative (best-effort).
+                      The old creative is retained for historical reporting. `videoId` and
+                      `existingCreativeId` are Meta-only and return 400.
                   properties:
                     headline: { type: string, description: "Meta and LinkedIn (TikTok has no headline slot)" }
                     body: { type: string }
@@ -41688,7 +41690,7 @@ paths:
                   ad: { $ref: '#/components/schemas/Ad' }
                   message: { type: string }
         '400':
-          description: Invalid status transition or budget below minimum
+          description: 'Invalid status transition, budget below minimum, or a LinkedIn creative update without imageUrl or videoUrl'
         '401': { $ref: '#/components/responses/Unauthorized' }
         '404': { $ref: '#/components/responses/NotFound' }
         '501': { description: "targeting or creative not supported on the platform (supported on Meta, TikTok, and LinkedIn)" }

data/spec/api/connect_api_spec.rb

@@ -257,7 +257,7 @@ describe 'ConnectApi' do
 
   # unit tests for get_pending_o_auth_data
   # Get pending OAuth data
-  # Fetch pending OAuth data for headless mode using the pendingDataToken from the redirect URL.  **Scope**: This endpoint is used for LinkedIn organizations, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook, Google Business and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).  Token is one-time use and expires after 10 minutes. No authentication required. 
+  # Fetch pending OAuth data for headless mode using the pendingDataToken from the redirect URL.  **Scope**: This endpoint is used for LinkedIn organizations, Google Business locations, Slack channels, Snapchat profiles, and Pinterest boards, where the selection list is too large to fit in URL params. The redirect carries a `pendingDataToken` instead of the full payload; the response includes the corresponding selection array (e.g. `boards` for Pinterest). WhatsApp, Facebook and other platforms pass selection state directly via URL query params on the redirect (`profileId`, `tempToken`, `step`), no pending record is created, so this endpoint will return 404 for those flows. Use the platform-specific selection endpoint instead (e.g. `/v1/connect/whatsapp/select-phone-number`).  Reading the token does not consume it, so this fetch is repeatable until the token expires 1 hour after issuance. Completing the platform selection deletes the pending record, so the token stops working from then on. No authentication required. 
   # @param token The pending data token from the OAuth redirect URL (pendingDataToken parameter)
   # @param [Hash] opts the optional parameters
   # @return [GetPendingOAuthData200Response]

data/spec/api/webhooks_api_spec.rb

@@ -86,7 +86,7 @@ describe 'WebhooksApi' do
 
   # unit tests for redeliver_webhook_event
   # Redeliver a webhook event
-  # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 500. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
+  # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 422. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
   # @param redeliver_webhook_event_request 
   # @param [Hash] opts the optional parameters
   # @return [UnpublishPost200Response]

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: late-sdk
 version: !ruby/object:Gem::Version
-  version: 0.0.815
+  version: 0.0.817
 platform: ruby
 authors:
 - OpenAPI-Generator
@@ -5557,7 +5557,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.815.gem
+- zernio-sdk-0.0.817.gem
 - zernio-sdk.gemspec
 homepage: https://openapi-generator.tech
 licenses: