late-sdk 0.0.871 → 0.0.873

data/spec/api/phone_numbers_api_spec.rb

@@ -72,7 +72,7 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for create_phone_number_kyc_link
   # Create a hosted KYC link
-  # Create a single-use, 7-day hosted KYC link that your end customer completes WITHOUT a Zernio login — useful when the person who holds the ID and address is not your team. They fill the regulated verification on a Zernio-hosted page; the number provisions under YOUR account once they submit. Only regulated (KYC) countries are valid: a country that does not require KYC returns 400.  White-label the page with `branding` (your company name, logo, brand color). Supply `redirect_url` to send the end customer back to your own site after a successful submit (completion params are appended — see below). Listen for the `whatsapp.number.kyc_submitted` webhook to react when the form is completed. 
+  # Create a single-use, 7-day hosted KYC link that your end customer completes WITHOUT a Zernio login. Useful when the person who holds the ID and address is not your team. They fill the regulated verification on a Zernio-hosted page; the number provisions under YOUR account once they submit. Only regulated (KYC) countries are valid: a country that does not require KYC returns 400.  White-label the page with `branding` (your company name, logo, brand color). Supply `redirect_url` to send the end customer back to your own site after a successful submit (completion params are appended; see below). Listen for the `whatsapp.number.kyc_submitted` webhook to react when the form is completed. 
   # @param create_phone_number_kyc_link_request 
   # @param [Hash] opts the optional parameters
   # @return [CreatePhoneNumberKycLink200Response]
@@ -84,7 +84,7 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for create_phone_number_port_in
   # Port numbers in
-  # Submit a port-in for one or more existing numbers from another carrier. Creates the carrier order(s), attaches the end-user (current account) info plus the LOA and invoice documents, and submits to the losing carrier. The transfer PIN is forwarded to the carrier and never stored. Ported numbers arrive voice-ready (and SMS-ready where the order supports messaging).  Run the portability check (POST /v1/phone-numbers/port-in/check) and upload the two documents (POST /v1/phone-numbers/port-in/documents) first — uploaded documents must be attached to an order within 30 minutes or the carrier deletes them, so upload right before this call. The carrier may split the numbers into several orders (by country, number type, losing carrier); `orders` carries per-order results, and a partial failure still returns 201 with the failed orders' `error` set (they stay as cancellable drafts).  Non-US/CA numbers additionally need the country-specific values from GET /v1/phone-numbers/port-in/requirements, passed via `requirements`, and must be submitted one country per request. When required information is still missing after submission, the order is kept as a resumable draft whose `error` / `declineReason` names the gaps. 
+  # Submit a port-in for one or more existing numbers from another carrier. Creates the carrier order(s), attaches the end-user (current account) info plus the LOA and invoice documents, and submits to the losing carrier. The transfer PIN is forwarded to the carrier and never stored. Ported numbers arrive voice-ready (and SMS-ready where the order supports messaging).  Run the portability check (POST /v1/phone-numbers/port-in/check) and upload the two documents (POST /v1/phone-numbers/port-in/documents) first. Uploaded documents must be attached to an order within 30 minutes or the carrier deletes them, so upload right before this call. The carrier may split the numbers into several orders (by country, number type, losing carrier); `orders` carries per-order results, and a partial failure still returns 201 with the failed orders' `error` set (they stay as cancellable drafts).  Non-US/CA numbers additionally need the country-specific values from GET /v1/phone-numbers/port-in/requirements, passed via `requirements`, and must be submitted one country per request. When required information is still missing after submission, the order is kept as a resumable draft whose `error` / `declineReason` names the gaps. 
   # @param create_phone_number_port_in_request 
   # @param [Hash] opts the optional parameters
   # @return [CreatePhoneNumberPortIn201Response]
@@ -119,7 +119,7 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for get_phone_number
   # Get phone number
-  # Retrieve the current status of a purchased phone number. Poll this to track Meta pre-verification (US sync path) and, for regulated (Tier 3/4) numbers, the async lifecycle: pending_regulatory → active (or regulatory_declined). When a regulated number has an Onfido ID step, `onfidoVerificationUrl` appears here once the order is placed — forward it to the end user. (Or subscribe to the whatsapp.number.* webhooks instead of polling.) 
+  # Retrieve the current status of a purchased phone number. Poll this to track Meta pre-verification (US sync path) and, for regulated (Tier 3/4) numbers, the async lifecycle: pending_regulatory → active (or regulatory_declined). When a regulated number has an Onfido ID step, `onfidoVerificationUrl` appears here once the order is placed. Forward it to the end user. (Or subscribe to the whatsapp.number.* webhooks instead of polling.) 
   # @param id Phone number record ID
   # @param [Hash] opts the optional parameters
   # @return [GetPhoneNumber200Response]
@@ -156,10 +156,10 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for get_phone_number_port_in_requirements
   # Country porting requirements
-  # The country-specific information a port-in needs BEYOND the LOA, invoice, and account/address details — e.g. an ID copy, proof of address, a tax id, or a porting code. Call it after the portability check (which returns each number's `countryCode` and `phoneNumberType`), render the fields, and pass the collected values as the create request's `requirements`. US/CA return an empty list. 
+  # The country-specific information a port-in needs BEYOND the LOA, invoice, and account/address details, such as an ID copy, proof of address, a tax id, or a porting code. Call it after the portability check (which returns each number's `countryCode` and `phoneNumberType`), render the fields, and pass the collected values as the create request's `requirements`. US/CA return an empty list. 
   # @param country ISO country of the numbers being ported (a supported port-in country).
   # @param [Hash] opts the optional parameters
-  # @option opts [String] :number_type The portability check's phoneNumberType — requirements differ by type.
+  # @option opts [String] :number_type The portability check's phoneNumberType. Requirements differ by type.
   # @return [GetPhoneNumberPortInRequirements200Response]
   describe 'get_phone_number_port_in_requirements test' do
     it 'should work' do
@@ -169,7 +169,7 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for get_phone_number_remediation
   # Get declined requirements
-  # For a number in `regulatory_declined`, returns ONLY the requirements the reviewer flagged declined, as a form spec (same shape as the KYC form GET). The customer fixes just those — Telnyx supports correcting a declined requirement group and re-submitting it (no new number/group). Falls back to the full spec if the provider exposes no per-requirement flags. 
+  # For a number in `regulatory_declined`, returns ONLY the requirements the reviewer flagged declined, as a form spec (same shape as the KYC form GET). The customer fixes only those, because Telnyx supports correcting a declined requirement group and re-submitting it (no new number/group). Falls back to the full spec if the provider exposes no per-requirement flags. 
   # @param id Phone number record ID.
   # @param [Hash] opts the optional parameters
   # @return [GetPhoneNumberRemediation200Response]
@@ -215,7 +215,7 @@ describe 'PhoneNumbersApi' do
   # List phone numbers
   # List all phone numbers purchased by the authenticated user. By default, released numbers are excluded. Connected (bring-your-own) WhatsApp numbers are returned in the separate `connected` array; they are not billed and have no provisioning lifecycle. 
   # @param [Hash] opts the optional parameters
-  # @option opts [String] :status Filter by status (by default excludes released numbers). NOTE: `status=pending_regulatory` returns the \"provisioning\" view — numbers still in review PLUS recently-declined (last 30 days) ones, so a failed registration surfaces (with `regulatoryDeclineReason`) instead of silently disappearing. Declined numbers can be re-submitted via POST /v1/phone-numbers/{id}/remediate. `verifying` is the short-lived state after the number is provisioned on our side while WhatsApp confirms the activation code; the number is not billed until it reaches `active`. 
+  # @option opts [String] :status Filter by status (by default excludes released numbers). NOTE: `status=pending_regulatory` returns the \"provisioning\" view: numbers still in review PLUS recently-declined (last 30 days) ones, so a failed registration surfaces (with `regulatoryDeclineReason`) instead of silently disappearing. Declined numbers can be re-submitted via POST /v1/phone-numbers/{id}/remediate. `verifying` is the short-lived state after the number is provisioned on our side while WhatsApp confirms the activation code; the number is not billed until it reaches `active`. 
   # @option opts [String] :profile_id Filter by profile
   # @return [ListPhoneNumbers200Response]
   describe 'list_phone_numbers test' do
@@ -238,7 +238,7 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for release_phone_number
   # Release phone number
-  # Release a purchased phone number. This will: 1. Disconnect any linked WhatsApp social account 2. Decrement the Stripe subscription quantity (or cancel if last number) 3. Release the number from Telnyx 4. Mark the number as released 
+  # Release a purchased phone number. This will: 1. Disconnect any linked WhatsApp account 2. Decrement the Stripe subscription quantity (or cancel if last number) 3. Release the number from Telnyx 4. Mark the number as released 
   # @param id Phone number record ID
   # @param [Hash] opts the optional parameters
   # @return [ReleasePhoneNumber200Response]
@@ -250,7 +250,7 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for remediate_phone_number
   # Resubmit a declined number
-  # Submit corrected values/documents for the declined requirement(s). We PATCH them onto the SAME requirement group and re-submit it for approval; the number goes `regulatory_declined` → `pending_regulatory`. No new number and no new billing. Body shape matches the KYC submit (values / documents / address) — send only the corrected fields. 
+  # Submit corrected values/documents for the declined requirement(s). We PATCH them onto the SAME requirement group and re-submit it for approval; the number goes `regulatory_declined` → `pending_regulatory`. No new number and no new billing. Body shape matches the KYC submit (values / documents / address). Send only the corrected fields. 
   # @param id 
   # @param remediate_phone_number_request 
   # @param [Hash] opts the optional parameters
@@ -263,7 +263,7 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for reply_to_phone_number_reviewer
   # Reply to the regulatory reviewer
-  # Post a free-text reply (with optional file attachments) to the reviewer on a number awaiting remediation — for asks the structured form can't express (e.g. \"is this personal or business?\"). Attachments are stored by us and their links are added to the reviewer's comment thread (the carrier's number order takes no loose files). A reply to a comment-style ask moves the number back to \"in review\"; a reply on a formal decline is supplementary and you must still resubmit the fix. Requires text or at least one attachment. 
+  # Post a free-text reply (with optional file attachments) to the reviewer on a number awaiting remediation, for asks the structured form can't express (e.g. \"is this personal or business?\"). Attachments are stored by us and their links are added to the reviewer's comment thread (the carrier's number order takes no loose files). A reply to a comment-style ask moves the number back to \"in review\"; a reply on a formal decline is supplementary and you must still resubmit the fix. Requires text or at least one attachment. 
   # @param id 
   # @param reply_to_phone_number_reviewer_request 
   # @param [Hash] opts the optional parameters
@@ -319,7 +319,7 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for submit_phone_number_kyc
   # Submit KYC
-  # Submit the end customer's KYC (textual values, uploaded documents, address) for a Tier 3/4 country. Documents are streamed straight to the number provider and are not stored by Zernio. Builds + submits a regulatory requirement group and claims a pending_regulatory slot; the number is ordered + activated once the provider approves (asynchronous). A customer may hold several same-country numbers in review at once; a double-submit of the SAME attempt is deduped via `submissionId`.  For an ID-card document requirement, carriers commonly require BOTH sides: combine the front and back into a single file before uploading (the dashboard does this automatically). A one-sided ID is a common decline reason; fix it via POST /v1/phone-numbers/{id}/remediate.  Before submitting, call GET /v1/phone-numbers/availability to check the country has deliverable inventory and, for geographic-match countries, which area the address must be in — otherwise the submission can pass review yet never be assignable a number. 
+  # Submit the end customer's KYC (textual values, uploaded documents, address) for a Tier 3/4 country. Documents are streamed straight to the number provider and are not stored by Zernio. Builds + submits a regulatory requirement group and claims a pending_regulatory slot; the number is ordered + activated once the provider approves (asynchronous). A customer may hold several same-country numbers in review at once; a double-submit of the SAME attempt is deduped via `submissionId`.  For an ID-card document requirement, carriers commonly require BOTH sides: combine the front and back into a single file before uploading (the dashboard does this automatically). A one-sided ID is a common decline reason; fix it via POST /v1/phone-numbers/{id}/remediate.  Before submitting, call GET /v1/phone-numbers/availability to check the country has deliverable inventory and, for geographic-match countries, which area the address must be in. Otherwise the submission can pass review yet never be assignable a number. 
   # @param submit_phone_number_kyc_request 
   # @param [Hash] opts the optional parameters
   # @return [SubmitPhoneNumberKyc200Response]
@@ -369,7 +369,7 @@ describe 'PhoneNumbersApi' do
 
   # unit tests for view_phone_number_kyc_document
   # View a KYC document on file
-  # Stream a document backing a reusable verification (the `documentId` values from GET /v1/phone-numbers/kyc `reusable.options[].details[]`), so the account holder can see what's on file before reusing it. Returned inline as `application/pdf` (uploads are normalized to PDF). Auth-scoped: a document is viewable only when its id is referenced by one of the caller's own numbers — otherwise `404`. 
+  # Stream a document backing a reusable verification (the `documentId` values from GET /v1/phone-numbers/kyc `reusable.options[].details[]`), so the account holder can see what's on file before reusing it. Returned inline as `application/pdf` (uploads are normalized to PDF). Auth-scoped: a document is viewable only when its id is referenced by one of the caller's own numbers. Otherwise `404`. 
   # @param document_id The Telnyx document id (from `reusable.options[].details[].documentId`).
   # @param [Hash] opts the optional parameters
   # @return [File]

data/spec/api/posts_api_spec.rb

@@ -47,7 +47,7 @@ describe 'PostsApi' do
 
   # unit tests for create_post
   # Create post
-  # Create and optionally publish a post. Immediate posts (`publishNow: true`) include `platformPostUrl` in the response. Content is optional when media is attached, all platforms have `customContent`, every platform entry is an X Article (`platformSpecificData.article`), or every platform entry is a LinkedIn text-free reshare (`platformSpecificData.reshareUrl` with no text). See each platform's schema for media constraints.  ## Scheduling  Pick one of `scheduledFor` (schedule), `publishNow: true` (publish synchronously) or `queuedFromProfile` (next queue slot). With none of them and `isDraft` unset, the post is saved as a draft. `platforms` is required unless the post is a draft. `isDraft: true` wins over `publishNow` and `scheduledFor` (the post is saved, never published); `publishNow: true` wins over `scheduledFor`. A `scheduledFor` already in the past is not rejected: the post is published synchronously in the same request, exactly like `publishNow`.  ## Idempotency  Two layers of duplicate-protection apply, so safe-to-retry callers (network blips, n8n / Zapier retries, etc.) don't accidentally double-post.  **1. Same-request idempotency (5-minute window).** Pass an `x-request-id` header to mark a logical request. If a second request arrives with the same `x-request-id` while the first is in-flight (or within ~5 minutes of completion), we return **HTTP 200** with the original post in the `existingPost` field — no new post is created. The official Zernio SDKs auto-generate a unique `x-request-id` per call. If you're using a generic HTTP client (curl, n8n's HTTP node, Zapier, custom code), either: - Set a unique `x-request-id` per logical call (recommended — UUIDv4 is fine) - Or simply omit the header — we'll treat each request as new  **Common pitfall**: if your workflow tool uses a single execution-level request ID and reuses it across multiple HTTP nodes (e.g. one ID for the whole run, shared across 6 different platform calls), every call after the first will look like a retry of the first and return its post. Generate a fresh ID per node.  **2. Content-hash dedup (24-hour window).** Independently, we hash `(platform, accountId, content + media URLs)` and reject duplicates within 24 hours with **HTTP 409**. This catches genuine \"same content posted twice to the same account\" cases regardless of `x-request-id`. Returns `error`, `accountId`, `platform`, and `existingPostId` so you can find the original. To intentionally re-post identical content within 24h, change something (the caption, the media, the account) — the dedup is keyed on the full content fingerprint.  Order: same-`x-request-id` retries (200) are checked first; if no idempotency match, the content-hash dedup (409) runs. 
+  # Create a post, and optionally publish it in the same request. A post published immediately (`publishNow: true`) comes back with `platformPostUrl` in the response.  `content` is optional in four cases:  - media is attached - all platforms have `customContent` - every platform entry is an X Article (`platformSpecificData.article`) - every platform entry is a LinkedIn text-free reshare (`platformSpecificData.reshareUrl` with no text)  See each platform's schema for media constraints.  ## Scheduling  Pick one of:  - `scheduledFor`: publish at the scheduled time - `publishNow: true`: publish synchronously, inside this request - `queuedFromProfile`: publish in the profile's next queue slot  With none of them and `isDraft` unset, the post is saved as a draft. `platforms` is required unless the post is a draft.  Precedence: `isDraft: true` wins over `publishNow` and `scheduledFor` (the post is saved, never published), and `publishNow: true` wins over `scheduledFor`. A `scheduledFor` already in the past is not rejected: the post is published synchronously in the same request, exactly like `publishNow`.  ## Idempotency  Two layers of duplicate-protection apply, so safe-to-retry callers (network blips, n8n / Zapier retries, etc.) don't accidentally double-post.  **1. Same-request idempotency (5-minute window).** Pass an `x-request-id` header to mark a logical request. If a second request arrives with the same `x-request-id` while the first is in-flight (or within ~5 minutes of completion), we return **HTTP 200** with the original post in the `existingPost` field, and no new post is created.  The official Zernio SDKs auto-generate a unique `x-request-id` per call. On a generic HTTP client (curl, n8n's HTTP node, Zapier, custom code), either:  - Set a unique `x-request-id` per logical call (recommended, UUIDv4 is fine) - Or omit the header, and we'll treat each request as new  **Common pitfall**: if your workflow tool uses a single execution-level request ID and reuses it across multiple HTTP nodes (e.g. one ID for the whole run, shared across 6 different platform calls), every call after the first will look like a retry of the first and return its post. Generate a fresh ID per node.  **2. Content-hash dedup (24-hour window).** Independently, we hash `(platform, accountId, content + media URLs)` and reject duplicates within 24 hours with **HTTP 409**. This catches genuine \"same content posted twice to the same account\" cases regardless of `x-request-id`. The response carries `error`, `accountId`, `platform`, and `existingPostId` so you can find the original.  To intentionally re-post identical content within 24h, change something (the caption, the media, the account), because the dedup is keyed on the full content fingerprint.  Order: same-`x-request-id` retries (200) are checked first; if no idempotency match, the content-hash dedup (409) runs. 
   # @param create_post_request 
   # @param [Hash] opts the optional parameters
   # @option opts [String] :x_request_id Optional client-generated request identifier for safe retry (idempotency). When two requests carry the same value, the second is treated as a retry of the first and returns the original post (HTTP 200) instead of creating a duplicate. Window is ~5 minutes from the first request. Generate a UUID per logical call. SDKs do this automatically; HTTP clients should set it themselves or omit it. See the operation description for the full idempotency contract. 
@@ -72,7 +72,7 @@ describe 'PostsApi' do
 
   # unit tests for edit_post
   # Edit published post
-  # Edit the text of an already-published post. Supported on X (Twitter), Discord, Facebook, Reddit, LinkedIn, Telegram, Pinterest, Google Business Profile, YouTube, and Slack. When a post was published to several accounts on the same platform, pass `accountId` to pick which account's copy to edit (the first entry is edited otherwise). Each platform enforces its own rules:  **X (Twitter)** - Connected X account must have an active X Premium subscription - Must be within 1 hour of original publish time - Maximum 5 edits per tweet (enforced by X) - Threads cannot be edited, only single tweets - X assigns a NEW post ID on edit, returned as `id`  **Discord** - No time limit and no premium requirement - The message ID is unchanged after the edit  **Facebook** - Graph only permits editing a post that the same app created, so this works on   posts published through Zernio and is rejected for posts created in Meta   Business Suite / Composer or by another tool - Media cannot be swapped, only the message text - Reactions, comments, and shares are preserved. The post ID is unchanged  **Reddit** - Self-posts only. A link post has no editable body and is rejected before the write - Body only. Reddit exposes no API to edit a post title, ever - The post ID is unchanged  **LinkedIn** - Text only, no time limit. Media, polls, articles, and reshare targets cannot be   changed - Works for member and organization posts published through this API. The post   keeps its ID and LinkedIn shows an \"edited\" marker - Text is limited to 3,000 characters; mentions and hashtags are preserved  **Telegram** - No time limit; messages published through Zernio are editable indefinitely - Text posts: edits the message text (up to 4096 characters) - Media posts: edits the caption only (up to 1024 characters). The media itself   cannot be swapped - For albums, the caption shown on the album (its first message) is edited - The message ID is unchanged  **Pinterest** - Description only, maximum 800 characters. Media, link, and board cannot be   changed, and a pin title derived from the old content's first line at publish   stays as-is - Pinterest's pin-update endpoint is currently in closed beta; until the app is   allowlisted by Pinterest, edits are rejected with a \"beta feature not yet   enabled\" error - The pin ID is unchanged  **Google Business Profile** - Post body (summary) text only. Call-to-action, event/offer fields, and media are   untouched - No time limit and no edit limit. The post ID is unchanged - The post must still exist on Google: a post deleted from the Business Profile   dashboard, or an event/offer post past its end date, returns a 404  **YouTube** - `content` replaces the video description only. The title is unchanged, even if   it was originally derived from the content's first line at publish time - Title, tags, thumbnail, and privacy edits belong to `POST /v1/posts/{postId}/update-metadata` - No time window and no edit cap. The video ID is unchanged  **Slack** - Text only, up to 4,000 characters. Media cannot be swapped, and media posts   whose share message reference never resolved cannot be edited - No time limit unless workspace admins restrict message editing - The message ID is unchanged  Media edits are not supported on any platform. The post record in Zernio is updated with the new content and an edit-history entry. 
+  # Edit the text of an already-published post. Supported on X, Discord, Facebook, Reddit, LinkedIn, Telegram, Pinterest, Google Business Profile, YouTube, and Slack. When a post was published to several accounts on the same platform, pass `accountId` to pick which account's copy to edit (the first entry is edited otherwise). Each platform enforces its own rules:  **X** - Connected X account must have an active X Premium subscription - Must be within 1 hour of original publish time - Maximum 5 edits per tweet (enforced by X) - Threads cannot be edited, only single tweets - X assigns a NEW post ID on edit, returned as `id`  **Discord** - No time limit and no premium requirement - The message ID is unchanged after the edit  **Facebook** - Graph only permits editing a post that the same app created, so this works on   posts published through Zernio and is rejected for posts created in Meta   Business Suite / Composer or by another tool - Media cannot be swapped, only the message text - Reactions, comments, and shares are preserved. The post ID is unchanged  **Reddit** - Self-posts only. A link post has no editable body and is rejected before the write - Body only. Reddit exposes no API to edit a post title, ever - The post ID is unchanged  **LinkedIn** - Text only, no time limit. Media, polls, articles, and reshare targets cannot be   changed - Works for member and organization posts published through this API. The post   keeps its ID and LinkedIn shows an \"edited\" marker - Text is limited to 3,000 characters; mentions and hashtags are preserved  **Telegram** - No time limit; messages published through Zernio are editable indefinitely - Text posts: edits the message text (up to 4096 characters) - Media posts: edits the caption only (up to 1024 characters). The media itself   cannot be swapped - For albums, the caption shown on the album (its first message) is edited - The message ID is unchanged  **Pinterest** - Description only, maximum 800 characters. Media, link, and board cannot be   changed, and a pin title derived from the old content's first line at publish   stays as-is - Pinterest's pin-update endpoint is currently in closed beta; until the app is   allowlisted by Pinterest, edits are rejected with a \"beta feature not yet   enabled\" error - The pin ID is unchanged  **Google Business Profile** - Post body (summary) text only. Call-to-action, event/offer fields, and media are   untouched - No time limit and no edit limit. The post ID is unchanged - The post must still exist on Google: a post deleted from the Business Profile   dashboard, or an event/offer post past its end date, returns a 404  **YouTube** - `content` replaces the video description only. The title is unchanged, even if   it was originally derived from the content's first line at publish time - Title, tags, thumbnail, and privacy edits belong to `POST /v1/posts/{postId}/update-metadata` - No time window and no edit cap. The video ID is unchanged  **Slack** - Text only, up to 4,000 characters. Media cannot be swapped, and media posts   whose share message reference never resolved cannot be edited - No time limit unless workspace admins restrict message editing - The message ID is unchanged  Media edits are not supported on any platform. The post record in Zernio is updated with the new content and an edit-history entry. 
   # @param post_id 
   # @param edit_post_request 
   # @param [Hash] opts the optional parameters
@@ -111,7 +111,7 @@ describe 'PostsApi' do
   # @option opts [Boolean] :include_hidden 
   # @option opts [String] :search Search posts by text content.
   # @option opts [String] :sort_by Sort order for results.
-  # @option opts [String] :account_id Filter posts to those published via a specific social account (24-char hex ObjectId).
+  # @option opts [String] :account_id Filter posts to those published via a specific account (24-char hex ObjectId).
   # @return [PostsListResponse]
   describe 'list_posts test' do
     it 'should work' do
@@ -159,7 +159,7 @@ describe 'PostsApi' do
 
   # unit tests for update_post_metadata
   # Update post metadata
-  # Updates metadata of a published video on the specified platform without re-uploading. Currently only supported for YouTube. At least one updatable field is required.  Two modes:  1. Post-based (video published through Zernio): pass the Zernio postId in the URL and platform in the body. 2. Direct video ID (video uploaded outside Zernio, e.g. directly to YouTube): use _ as the postId,    and pass videoId + accountId + platform in the body. The accountId is the Zernio social account ID    for the connected YouTube channel. 
+  # Updates metadata of a published video on the specified platform without re-uploading. Currently only supported for YouTube. At least one updatable field is required.  Two modes:  1. Post-based (video published through Zernio): pass the Zernio postId in the URL and platform in the body. 2. Direct video ID (video uploaded outside Zernio, e.g. directly to YouTube): use _ as the postId,    and pass videoId + accountId + platform in the body. The accountId is the Zernio account ID    for the connected YouTube channel. 
   # @param post_id Zernio post ID, or \"_\" when using direct video ID mode
   # @param update_post_metadata_request 
   # @param [Hash] opts the optional parameters

data/spec/api/profiles_api_spec.rb

@@ -34,7 +34,7 @@ describe 'ProfilesApi' do
 
   # unit tests for create_profile
   # Create profile
-  # Creates a new profile with a name, optional description, and color. Names are unique per workspace: a duplicate returns a 409 whose details.existingProfileId carries the id of the existing profile. Send an Idempotency-Key header to make retries safe: a retried create with the same key and body replays the original 201 (same _id) instead of conflicting.
+  # Creates a new profile with a name, optional description, and color. Names are unique per team: a duplicate returns a 409 whose details.existingProfileId carries the id of the existing profile. Send an Idempotency-Key header to make retries safe: a retried create with the same key and body replays the original 201 (same _id) instead of conflicting.
   # @param create_profile_request 
   # @param [Hash] opts the optional parameters
   # @option opts [String] :idempotency_key Optional client-generated unique key (e.g. a UUID) that makes retries safe. Same key + same body replays the original response; same key + different body → 422; key still processing → 409.

data/spec/api/reach_and_frequency_api_spec.rb

@@ -48,7 +48,7 @@ describe 'ReachAndFrequencyApi' do
 
   # unit tests for create_rf_prediction
   # Create a Reach & Frequency prediction
-  # Creates an R&F prediction — a QUOTE, nothing is bought and no ad entities are created. Provide a date range plus exactly one of `budgetAmount` (Meta predicts reach) or `reach` (Meta predicts the budget). The response carries the estimate and its allowed bounds (min/max budget and reach). Predictions expire on their own; to buy, reserve one via POST /v1/ads/rf-predictions/{predictionId}/reserve and pass the RESERVED id to POST /v1/ads/create with `buyingType: \"RESERVED\"`.  Reservation campaigns reject automatic placements. Top-level `placements` wins; when it is omitted, `targeting.placements` is used; when neither is set, placements default to Facebook feed (+ Instagram stream when a linked IG professional account resolves). Instagram placements require that IG account.
+  # Creates an R&F prediction. This is a QUOTE, nothing is bought and no ad entities are created. Provide a date range plus exactly one of `budgetAmount` (Meta predicts reach) or `reach` (Meta predicts the budget). The response carries the estimate and its allowed bounds (min/max budget and reach). Predictions expire on their own; to buy, reserve one via POST /v1/ads/rf-predictions/{predictionId}/reserve and pass the RESERVED id to POST /v1/ads/create with `buyingType: \"RESERVED\"`.  Reservation campaigns reject automatic placements. Top-level `placements` wins; when it is omitted, `targeting.placements` is used; when neither is set, placements default to Facebook feed (+ Instagram stream when a linked IG professional account resolves). Instagram placements require that IG account.
   # @param create_rf_prediction_request 
   # @param [Hash] opts the optional parameters
   # @return [CreateRfPrediction201Response]
@@ -73,7 +73,7 @@ describe 'ReachAndFrequencyApi' do
 
   # unit tests for reserve_rf_prediction
   # Reserve a Reach & Frequency prediction
-  # Locks the quoted price + inventory until the returned `expiresAt` and mints a NEW prediction id — pass that RESERVED id (not the original) as `rfPredictionId` on POST /v1/ads/create. Release an unused reservation via DELETE.
+  # Locks the quoted price + inventory until the returned `expiresAt` and mints a NEW prediction id. Pass that RESERVED id (not the original) as `rfPredictionId` on POST /v1/ads/create. Release an unused reservation via DELETE.
   # @param prediction_id 
   # @param reserve_rf_prediction_request 
   # @param [Hash] opts the optional parameters

data/spec/api/reviews_api_spec.rb

@@ -34,7 +34,7 @@ describe 'ReviewsApi' do
 
   # unit tests for delete_inbox_review_reply
   # Delete review reply
-  # Delete a reply to a review (Google Business only). Requires accountId in request body.
+  # Delete a reply to a review (Google Business Profile only). Requires accountId in request body.
   # @param review_id 
   # @param delete_inbox_review_reply_request 
   # @param [Hash] opts the optional parameters
@@ -47,7 +47,7 @@ describe 'ReviewsApi' do
 
   # unit tests for list_inbox_reviews
   # List reviews
-  # Fetch reviews from all connected Facebook Pages and Google Business accounts. Aggregates data with filtering and sorting options. Supported platforms: Facebook, Google Business. 
+  # Fetch reviews from all connected Facebook Pages and Google Business Profile accounts. Aggregates data with filtering and sorting options. Supported platforms: Facebook, Google Business Profile. 
   # @param [Hash] opts the optional parameters
   # @option opts [String] :profile_id 
   # @option opts [String] :platform 
@@ -58,7 +58,7 @@ describe 'ReviewsApi' do
   # @option opts [String] :sort_order 
   # @option opts [Integer] :limit 
   # @option opts [String] :cursor 
-  # @option opts [String] :account_id Filter by specific social account ID
+  # @option opts [String] :account_id Filter by specific account ID
   # @return [ListInboxReviews200Response]
   describe 'list_inbox_reviews test' do
     it 'should work' do
@@ -69,7 +69,7 @@ describe 'ReviewsApi' do
   # unit tests for reply_to_inbox_review
   # Reply to review
   # Post a reply to a review. Requires accountId in request body.  **Idempotency:** send an `Idempotency-Key` header to make retries safe (e.g. after a client-side timeout where delivery is unknown): same key + same body replays the original response (with `Idempotent-Replayed: true`) instead of sending the reply to the platform again; same key + different body returns 422; a key still in flight returns 409. Keys are retained for 24 hours and are scoped to the credential and to this exact path, so reusing a key against a different reviewId returns 422 rather than replaying the other review's response.  Only successful (2xx) responses are stored for replay. If the request throws or returns a non-2xx status the key is released, so the header protects the \"request succeeded but the response was lost\" case. After an ambiguous failure (a 5xx or a network timeout) fetch the review before retrying with the same key, and treat a missing reply as inconclusive rather than as proof nothing was sent. 
-  # @param review_id Review ID (URL-encoded for Google Business)
+  # @param review_id Review ID (URL-encoded for Google Business Profile)
   # @param reply_to_inbox_review_request 
   # @param [Hash] opts the optional parameters
   # @option opts [String] :idempotency_key Optional client-generated unique key (e.g. a UUID) that makes retries safe. Same key + same body replays the original response; same key + different body → 422; key still processing → 409.

data/spec/api/sms_api_spec.rb

@@ -47,7 +47,7 @@ describe 'SMSApi' do
 
   # unit tests for create_sms_sender_id
   # Create an alphanumeric sender ID
-  # Registers an alphanumeric sender ID (e.g. `ZERNIO`) — a branded `from` for one-way international SMS. No phone number purchase or carrier registration is needed; once created, pass it as `from` on `POST /v1/sms/messages`.  Constraints: 3-11 characters (letters, digits, spaces; at least one letter). Sends cannot reach the US, Canada, or Puerto Rico, are text-only, and recipients cannot reply. Sender IDs that impersonate well-known brands or institutions are rejected. Names are not exclusive: the same sender ID can be registered by any number of workspaces. Creating the same sender ID again is a no-op (re-activates it after a delete). 
+  # Registers an alphanumeric sender ID (e.g. `ZERNIO`), a branded `from` for one-way international SMS. No phone number purchase or carrier registration is needed; once created, pass it as `from` on `POST /v1/sms/messages`.  Constraints: 3-11 characters (letters, digits, spaces; at least one letter). Sends cannot reach the US, Canada, or Puerto Rico, are text-only, and recipients cannot reply. Sender IDs that impersonate well-known brands or institutions are rejected. Names are not exclusive: the same sender ID can be registered by any number of teams. Creating the same sender ID again is a no-op (re-activates it after a delete). 
   # @param create_sms_sender_id_request 
   # @param [Hash] opts the optional parameters
   # @return [CreateSmsSenderId200Response]
@@ -59,7 +59,7 @@ describe 'SMSApi' do
 
   # unit tests for deactivate_sms_registration
   # Deactivate a brand/campaign registration
-  # Terminates the campaign with the carrier registry so the recurring monthly campaign fee stops (carriers bill the first 3 months of a campaign regardless). Numbers covered by it can no longer SEND texts — receiving is unaffected — until they're registered under a new brand. Irreversible: a deactivated campaign cannot be restored; texting again later requires a new registration (new one-time and review fees). Idempotent. 
+  # Terminates the campaign with the carrier registry so the recurring monthly campaign fee stops (carriers bill the first 3 months of a campaign regardless). Numbers covered by it can no longer SEND texts (receiving is unaffected) until they're registered under a new brand. Irreversible: a deactivated campaign cannot be restored; texting again later requires a new registration (new one-time and review fees). Idempotent. 
   # @param id 
   # @param [Hash] opts the optional parameters
   # @return [DeactivateSmsRegistration200Response]
@@ -83,7 +83,7 @@ describe 'SMSApi' do
 
   # unit tests for disable_sms_on_number
   # Disable SMS on a number
-  # Turns off SMS for the number (deactivates its SMS account). The carrier registration is untouched, so re-enabling later just reactivates it, with no re-registration. 
+  # Turns off SMS for the number (deactivates its SMS account). The carrier registration is untouched, so re-enabling later reactivates it, with no re-registration. 
   # @param id 
   # @param [Hash] opts the optional parameters
   # @return [DisableSmsOnNumber200Response]
@@ -95,7 +95,7 @@ describe 'SMSApi' do
 
   # unit tests for enable_sms_on_number
   # Enable SMS on a number
-  # Turns on SMS for one of your numbers. The number's real carrier capability is checked first: some number types can't do SMS at all (`smsCapable: false`), and a number still provisioning at the carrier returns `notReady: true` (try again once provisioning finishes).  US numbers additionally need a carrier registration before messages deliver; the response tells you which path applies: - `alreadyRegistered: true`: a prior registration still covers this   number; SMS was simply reactivated. - `reusable` set: you have an approved registration this number can   join in one click via   `POST /v1/phone-numbers/{id}/sms/reuse-registration`   (no new brand/campaign, no extra carrier fee). - `needsRegistration: true` and no `reusable`: start one via   `POST /v1/sms/registrations`.  Idempotent: re-running re-attempts any carrier-side setup that failed. 
+  # Turns on SMS for one of your numbers. The number's real carrier capability is checked first: some number types can't do SMS at all (`smsCapable: false`), and a number still provisioning at the carrier returns `notReady: true` (try again once provisioning finishes).  US numbers additionally need a carrier registration before messages deliver; the response tells you which path applies: - `alreadyRegistered: true`: a prior registration still covers this   number; SMS was reactivated. - `reusable` set: you have an approved registration this number can   join in one click via   `POST /v1/phone-numbers/{id}/sms/reuse-registration`   (no new brand/campaign, no extra carrier fee). - `needsRegistration: true` and no `reusable`: start one via   `POST /v1/sms/registrations`.  Idempotent: re-running re-attempts any carrier-side setup that failed. 
   # @param id Phone number record ID (from GET /v1/phone-numbers).
   # @param [Hash] opts the optional parameters
   # @return [EnableSmsOnNumber200Response]
@@ -133,7 +133,7 @@ describe 'SMSApi' do
   # unit tests for list_sms_registrations
   # List carrier registrations
   # @param [Hash] opts the optional parameters
-  # @option opts [Boolean] :include_deactivated Deactivated (terminated) registrations are hidden by default — pass true to include them.
+  # @option opts [Boolean] :include_deactivated Deactivated (terminated) registrations are hidden by default. Pass true to include them.
   # @return [ListSmsRegistrations200Response]
   describe 'list_sms_registrations test' do
     it 'should work' do
@@ -177,7 +177,7 @@ describe 'SMSApi' do
 
   # unit tests for request_sms_sender_id_limit_increase
   # Request a higher sender ID daily limit
-  # Asks support to raise the workspace's daily sender-ID message cap. There is no self-serve raise: the request (desired cap + use case) is reviewed manually, usually within a business day. 
+  # Asks support to raise the team's daily sender-ID message cap. There is no self-serve raise: the request (desired cap + use case) is reviewed manually, usually within a business day. 
   # @param request_sms_sender_id_limit_increase_request 
   # @param [Hash] opts the optional parameters
   # @return [RequestSmsSenderIdLimitIncrease200Response]
@@ -189,7 +189,7 @@ describe 'SMSApi' do
 
   # unit tests for resend_sms_registration_otp
   # Re-send the sole-prop OTP
-  # Re-sends the sole-proprietor verification PIN to the brand's mobile number — use it when the original code expired or never arrived. Only valid while the registration is pending and awaiting its OTP; rate limited to one send per minute. 
+  # Re-sends the sole-proprietor verification PIN to the brand's mobile number. Use it when the original code expired or never arrived. Only valid while the registration is pending and awaiting its OTP; rate limited to one send per minute. 
   # @param id 
   # @param [Hash] opts the optional parameters
   # @return [ResendSmsRegistrationOtp200Response]
@@ -201,7 +201,7 @@ describe 'SMSApi' do
 
   # unit tests for respond_to_sms_registration_review
   # Reply to a change request
-  # Replies to a reviewer change request on a registration in `changes_requested` state: a note, hosted document URLs (from `POST /v1/sms/opt-in-proof`), or both, sent together. The registration returns to `requested` (back in review) — no need to resubmit the whole registration. To change the submitted brand/campaign fields themselves, resubmit via `POST /v1/sms/registrations` with `resubmitRequestId` instead. 
+  # Replies to a reviewer change request on a registration in `changes_requested` state: a note, hosted document URLs (from `POST /v1/sms/opt-in-proof`), or both, sent together. The registration returns to `requested` (back in review), and you do not need to resubmit the whole registration. To change the submitted brand/campaign fields themselves, resubmit via `POST /v1/sms/registrations` with `resubmitRequestId` instead. 
   # @param id 
   # @param respond_to_sms_registration_review_request 
   # @param [Hash] opts the optional parameters
@@ -263,7 +263,7 @@ describe 'SMSApi' do
 
   # unit tests for upload_sms_opt_in_proof
   # Upload opt-in form proof for an appeal
-  # Hosts a screenshot (or PDF) of your SMS opt-in form and returns its public URL. Carrier reviewers reject campaigns whose consent can't be verified and ask for a \"link/screenshot of the opt-in form\" — the registry has no attachment field, so include the returned URL inside the `messageFlow` you submit with the appeal (`POST /v1/sms/registrations/{id}/appeal`). 
+  # Hosts a screenshot (or PDF) of your SMS opt-in form and returns its public URL. Carrier reviewers reject campaigns whose consent can't be verified and ask for a \"link/screenshot of the opt-in form\". The registry has no attachment field, so include the returned URL inside the `messageFlow` you submit with the appeal (`POST /v1/sms/registrations/{id}/appeal`). 
   # @param id 
   # @param file PNG, JPG, WebP, GIF or PDF, max 4MB.
   # @param [Hash] opts the optional parameters
@@ -276,7 +276,7 @@ describe 'SMSApi' do
 
   # unit tests for upload_sms_opt_in_proof_file
   # Upload opt-in form proof
-  # Hosts a screenshot (or PDF) of your SMS opt-in form and returns its public URL. Include that URL in the campaign's `messageFlow` (the opt-in workflow text) — the carrier registry has no attachment field, so reviewers verify consent by opening links in that answer. Works before a registration exists (use it when registering) and for appeals. `/v1/sms/registrations/{id}/opt-in-proof` is an alias. 
+  # Hosts a screenshot (or PDF) of your SMS opt-in form and returns its public URL. Include that URL in the campaign's `messageFlow` (the opt-in workflow text). The carrier registry has no attachment field, so reviewers verify consent by opening links in that answer. Works before a registration exists (use it when registering) and for appeals. `/v1/sms/registrations/{id}/opt-in-proof` is an alias. 
   # @param file PNG, JPG, WebP, GIF or PDF, max 4MB.
   # @param [Hash] opts the optional parameters
   # @return [UploadSmsOptInProofFile200Response]

data/spec/api/tracking_tags_api_spec.rb

@@ -48,7 +48,7 @@ describe 'TrackingTagsApi' do
 
   # unit tests for create_tracking_tag
   # Create a tracking tag
-  # Meta: creates a Meta Pixel on the given ad account (`POST /act_{id}/adspixels` — `name` is the only input). Returns the created tag including its install `code`. The pixel is owned by the Business Manager that owns the ad account; a pixel created on a personal (non-BM) ad account ends up with `ownerBusinessId: null` and can't be shared with other ad accounts.  Creating a Meta pixel does NOT install it — install the returned `code` snippet on the site, or send events server-side via `POST /v1/ads/conversions`. The check `installed` is derived from `lastFiredTime`.  OpenAI Ads: creates an OpenAI pixel AND provisions a Conversions API key for it in the same call (`adAccountId` is required by this endpoint but ignored — one API key maps to exactly one ad account, so there's nothing to select). Returns 422 (`FEATURE_NOT_AVAILABLE`) if the ad account isn't enabled for pixel management; contact your OpenAI partner representative to enable it. There is no delete API for OpenAI pixels. If the pixel is created but the Conversions API key provisioning then fails, the pixel is left live on OpenAI (it cannot be cleaned up) and the error message names the surviving pixel id and warns against retrying, since a retry would create a second, orphaned pixel.  NOT idempotent on either platform: each call creates a new pixel (and, for OpenAI, a new Conversions API key plus, with `defaultEventType`, a new conversion event setting). Do not retry blindly on timeout. Meta (platform `metaads`) and OpenAI Ads (platform `openaiads`); other platforms return 405. 
+  # Meta: creates a Meta Pixel on the given ad account (`POST /act_{id}/adspixels`, where `name` is the only input). Returns the created tag including its install `code`. The pixel is owned by the Business Manager that owns the ad account; a pixel created on a personal (non-BM) ad account ends up with `ownerBusinessId: null` and can't be shared with other ad accounts.  Creating a Meta pixel does NOT install it. Install the returned `code` snippet on the site, or send events server-side via `POST /v1/ads/conversions`. The check `installed` is derived from `lastFiredTime`.  OpenAI Ads: creates an OpenAI pixel AND provisions a Conversions API key for it in the same call (`adAccountId` is required by this endpoint but ignored: one API key maps to exactly one ad account, so there's nothing to select). Returns 422 (`FEATURE_NOT_AVAILABLE`) if the ad account isn't enabled for pixel management; contact your OpenAI partner representative to enable it. There is no delete API for OpenAI pixels. If the pixel is created but the Conversions API key provisioning then fails, the pixel is left live on OpenAI (it cannot be cleaned up) and the error message names the surviving pixel id and warns against retrying, since a retry would create a second, orphaned pixel.  NOT idempotent on either platform: each call creates a new pixel (and, for OpenAI, a new Conversions API key plus, with `defaultEventType`, a new conversion event setting). Do not retry blindly on timeout. Meta (platform `metaads`) and OpenAI Ads (platform `openaiads`); other platforms return 405. 
   # @param account_id Ads SocialAccount id (platform `metaads` or `openaiads`).
   # @param create_tracking_tag_request 
   # @param [Hash] opts the optional parameters
@@ -73,7 +73,7 @@ describe 'TrackingTagsApi' do
 
   # unit tests for get_tracking_tag
   # Get a tracking tag
-  # Returns the full tag record including the base-code `code` snippet, `lastFiredTime`, `ownerBusinessId`, `isUnavailable`, etc. Meta only (platform `metaads`); other platforms return 405. OpenAI Ads has no get-by-id endpoint, so it 405s here too — use `GET /v1/accounts/{accountId}/tracking-tags` (list) instead. 
+  # Returns the full tag record including the base-code `code` snippet, `lastFiredTime`, `ownerBusinessId`, `isUnavailable`, etc. Meta only (platform `metaads`); other platforms return 405. OpenAI Ads has no get-by-id endpoint, so it 405s here too. Use `GET /v1/accounts/{accountId}/tracking-tags` (list) instead. 
   # @param account_id 
   # @param tag_id Pixel id.
   # @param [Hash] opts the optional parameters
@@ -86,7 +86,7 @@ describe 'TrackingTagsApi' do
 
   # unit tests for get_tracking_tag_stats
   # Get aggregated event stats
-  # Returns aggregated event counts for the pixel (`GET /{pixel_id}/stats`). Rows are passed through from Meta as-is — their shape depends on the `aggregation` requested. Meta only (platform `metaads`); other platforms return 405. 
+  # Returns aggregated event counts for the pixel (`GET /{pixel_id}/stats`). Rows are passed through from Meta as-is; their shape depends on the `aggregation` requested. Meta only (platform `metaads`); other platforms return 405. 
   # @param account_id 
   # @param tag_id Pixel id.
   # @param [Hash] opts the optional parameters
@@ -115,7 +115,7 @@ describe 'TrackingTagsApi' do
 
   # unit tests for list_tracking_tags
   # List tracking tags
-  # Returns the tracking tags (Meta Pixels, or OpenAI Ads pixels) the connected ads account can see. Pass `?adAccountId=act_...` (Meta only) to scope the list to a single ad account; omit it to list every pixel reachable by the token (the name is then suffixed with the ad account it was discovered on, for disambiguation). The list view omits `code` — call `getTrackingTag` for the install snippet and full detail (Meta only; OpenAI Ads has no get-by-id endpoint).  Meta (platform `metaads`) and OpenAI Ads (platform `openaiads`); other platforms return 405. The `accountId` must be the ads SocialAccount created by the Ads add-on connect flow (Meta) or the OpenAI Ads connect flow, not a Facebook/Instagram posting account. Get your Meta `act_...` ids from `GET /v1/ads/accounts`; `adAccountId` is ignored for OpenAI Ads (one API key maps to exactly one ad account). 
+  # Returns the tracking tags (Meta Pixels, or OpenAI Ads pixels) the connected ads account can see. Pass `?adAccountId=act_...` (Meta only) to scope the list to a single ad account; omit it to list every pixel reachable by the token (the name is then suffixed with the ad account it was discovered on, for disambiguation). The list view omits `code`. Call `getTrackingTag` for the install snippet and full detail (Meta only; OpenAI Ads has no get-by-id endpoint).  Meta (platform `metaads`) and OpenAI Ads (platform `openaiads`); other platforms return 405. The `accountId` must be the ads SocialAccount created by the Ads add-on connect flow (Meta) or the OpenAI Ads connect flow, not a Facebook/Instagram posting account. Get your Meta `act_...` ids from `GET /v1/ads/accounts`; `adAccountId` is ignored for OpenAI Ads (one API key maps to exactly one ad account). 
   # @param account_id Ads SocialAccount id (platform `metaads` or `openaiads`).
   # @param [Hash] opts the optional parameters
   # @option opts [String] :ad_account_id Optional, Meta only. Scope to one ad account, e.g. `act_123456789`. Ignored for OpenAI Ads.
@@ -142,7 +142,7 @@ describe 'TrackingTagsApi' do
 
   # unit tests for update_ad_tracking_tags
   # Set ad tracking tags
-  # Unified update. Send only the fields for the ad's platform: - Meta: `urlTags` (array of {key,value}). Meta creatives are immutable, so this rebuilds the   creative and repoints the ad. By DEFAULT we PRESERVE the existing creative verbatim   (re-post its object_story_spec + the new url_tags, reusing the image), so you send `urlTags`   ALONE — no need to read back headline/body/CTA. `creative` (headline, body, callToAction,   linkUrl, imageUrl) is OPTIONAL and only needed to rebuild explicitly, or for SHARE / page-post   / dark / asset_feed creatives whose object_story_spec Meta strips (those return 422 asking for   `creative`). - Google: `trackingUrlTemplate` and/or `finalUrlSuffix` (full template strings; account quota applies). - LinkedIn: `dynamicValueParameters` and/or `customValueParameters` (campaign-level Dynamic UTM). 
+  # Unified update. Send only the fields for the ad's platform: - Meta: `urlTags` (array of {key,value}). Meta creatives are immutable, so this rebuilds the   creative and repoints the ad. By DEFAULT we PRESERVE the existing creative verbatim   (re-post its object_story_spec + the new url_tags, reusing the image), so you send `urlTags`   ALONE, with no need to read back headline/body/CTA. `creative` (headline, body, callToAction,   linkUrl, imageUrl) is OPTIONAL and only needed to rebuild explicitly, or for SHARE / page-post   / dark / asset_feed creatives whose object_story_spec Meta strips (those return 422 asking for   `creative`). - Google: `trackingUrlTemplate` and/or `finalUrlSuffix` (full template strings; account quota applies). - LinkedIn: `dynamicValueParameters` and/or `customValueParameters` (campaign-level Dynamic UTM). 
   # @param ad_id 
   # @param update_ad_tracking_tags_request 
   # @param [Hash] opts the optional parameters
@@ -155,7 +155,7 @@ describe 'TrackingTagsApi' do
 
   # unit tests for update_tracking_tag
   # Update a tracking tag
-  # Partial-update a pixel. Whitelisted fields: `name` (rename), `enableAutomaticMatching`, `automaticMatchingFields`, `firstPartyCookieStatus`, `dataUseSetting`. At least one is required. Returns the re-fetched canonical tag. Meta only (platform `metaads`); other platforms return 405.  There is no DELETE — Meta has no API to delete a pixel. To stop using one, unshare it from your ad accounts (`DELETE .../tracking-tags/{tagId}/shared-accounts`) or disable it in Events Manager. 
+  # Partial-update a pixel. Whitelisted fields: `name` (rename), `enableAutomaticMatching`, `automaticMatchingFields`, `firstPartyCookieStatus`, `dataUseSetting`. At least one is required. Returns the re-fetched canonical tag. Meta only (platform `metaads`); other platforms return 405.  There is no DELETE: Meta has no API to delete a pixel. To stop using one, unshare it from your ad accounts (`DELETE .../tracking-tags/{tagId}/shared-accounts`) or disable it in Events Manager. 
   # @param account_id 
   # @param tag_id Pixel id.
   # @param update_tracking_tag_request 

data/spec/api/twitter_engagement_api_spec.rb

@@ -46,7 +46,7 @@ describe 'TwitterEngagementApi' do
 
   # unit tests for follow_user
   # Follow a user
-  # Follow a user on X/Twitter. Requires the follows.write OAuth scope. For protected accounts, a follow request is sent instead (pending_follow will be true). 
+  # Follow a user on X. Requires the follows.write OAuth scope. For protected accounts, a follow request is sent instead (pending_follow will be true). 
   # @param follow_user_request 
   # @param [Hash] opts the optional parameters
   # @return [FollowUser200Response]
@@ -59,7 +59,7 @@ describe 'TwitterEngagementApi' do
   # unit tests for get_tweet
   # Look up a tweet
   # Resolve a single tweet by ID or URL into its text, author and public metrics.  Use this to render a post you are referencing, e.g. the tweet quoted by a quote-style post. Unlike `/v1/twitter/search` this is not limited to the last 7 days and works for any tweet visible to the connected account.  Billed as an X posts read ($0.005). Repeat lookups of the same tweet within the same UTC day are charged once. 
-  # @param account_id The social account ID whose X token is used for the lookup
+  # @param account_id The account ID whose X token is used for the lookup
   # @param id Numeric tweet ID or a tweet URL (e.g. https://x.com/user/status/123...)
   # @param [Hash] opts the optional parameters
   # @return [GetTweet200Response]
@@ -96,8 +96,8 @@ describe 'TwitterEngagementApi' do
 
   # unit tests for search_tweets
   # Search recent tweets
-  # Search public tweets from the last 7 days matching an X search query, e.g. to discover tweets to reply to. The query string is passed through to X unchanged and supports X's search operators (`from:user`, `-is:retweet`, `is:reply`, `lang:en`, `\"exact phrase\"`, `conversation_id:123`, boolean `OR`, ...). Note that standalone operators like `is:` / `has:` / `lang:` must be combined with a keyword or `from:` clause.  To reply to a found tweet, pass its `id` as the twitter platform entry's `platformSpecificData.replyToTweetId` when creating a post.  Rate limit: 300 requests per 15-min window per connected account. 
-  # @param account_id The social account ID
+  # Search public tweets from the last 7 days matching an X search query, e.g. to discover tweets to reply to. The query string is passed through to X unchanged and supports X's search operators (`from:user`, `-is:retweet`, `is:reply`, `lang:en`, `\"exact phrase\"`, `conversation_id:123`, boolean `OR`, ...). Standalone operators like `is:` / `has:` / `lang:` must be combined with a keyword or `from:` clause.  To reply to a found tweet, pass its `id` as the twitter platform entry's `platformSpecificData.replyToTweetId` when creating a post.  Rate limit: 300 requests per 15-min window per connected account. 
+  # @param account_id The account ID
   # @param query X search query, max 512 characters. Operators are passed through unchanged; X rejects malformed queries with a 400.
   # @param [Hash] opts the optional parameters
   # @option opts [Integer] :limit Results per page. X requires a minimum of 10; values below 10 are rejected.
@@ -129,9 +129,9 @@ describe 'TwitterEngagementApi' do
 
   # unit tests for unfollow_user
   # Unfollow a user
-  # Unfollow a user on X/Twitter. 
+  # Unfollow a user on X. 
   # @param account_id 
-  # @param target_user_id The Twitter ID of the user to unfollow
+  # @param target_user_id The X ID of the user to unfollow
   # @param [Hash] opts the optional parameters
   # @return [UnfollowUser200Response]
   describe 'unfollow_user test' do

data/spec/api/usage_api_spec.rb

@@ -34,7 +34,7 @@ describe 'UsageApi' do
 
   # unit tests for get_billing
   # Account billing snapshot (plan, cycle, balance, caps, status)
-  # The billing \"wallet/statement\" view: current plan, billing cycle, accrued balance + remaining credits this period, spend caps, and payment / access status. This is the billing half of the legacy `/v1/usage-stats` snapshot — the per-product consumption half is metering and lives on `GET /v1/usage`.  Usage-based (Metronome) accounts get a populated `balance`; legacy Stripe accounts get `balance: null` plus a deprecated `legacy.limits` block and, when payment-blocked, `status.openInvoiceUrl` / `status.declineReason`. 
+  # The billing \"wallet/statement\" view: current plan, billing cycle, accrued balance + remaining credits this period, spend caps, and payment / access status. This is the billing half of the legacy `/v1/usage-stats` snapshot. The per-product consumption half is metering and lives on `GET /v1/usage`.  Accounts on usage-based billing get a populated `balance`; legacy Stripe accounts get `balance: null` plus a deprecated `legacy.limits` block and, when payment-blocked, `status.openInvoiceUrl` / `status.declineReason`. 
   # @param [Hash] opts the optional parameters
   # @return [BillingSnapshot]
   describe 'get_billing test' do
@@ -76,15 +76,15 @@ describe 'UsageApi' do
 
   # unit tests for get_usage
   # Usage snapshot (default) or billed-spend metering (with params)
-  # Dual-mode endpoint, selected by query params — fully backward compatible:  **Without metering params (the default):** the plan / quota / usage snapshot — plan name, billing period, limits, usage counts, access state. Identical to `GET /v1/usage-stats`. Existing integrations keep working unchanged.  **With `range`, `granularity`, `from`, or `to`:** usage METERING — billed spend (USD) by product family (`accounts`, `numbers`, `calls`, `sms`, `dlc`, `xApi`, `credits`, `other`) over the window, at `day` / `month` / `total` granularity, from Metronome's invoice breakdown (the CHARGE view — always reconciles with what gets billed). Also served at `GET /v1/usage/daily`. Usage-based accounts only — legacy Stripe accounts get `{ \"supported\": false, \"days\": [] }`.  **Attribution (metering mode):** `groupBy=profile|account` adds an `attribution` breakdown of the window's spend per profile or account, assembled from your own records and pro-rated against the invoice so `sum(groups) + unattributed` equals `totals` exactly. `profileId` / `accountId` instead project the whole payload (`days`, `totals`, `lineItems`) onto that one group; `peaks`, `callUsage` and `tax` are then `null` (workspace-level facts). Projected `days` spread the group's period share over each day (usage is attributed per period, not per day). Profile-scoped API keys and members only see their profiles' groups (`attribution.restricted: true`, with `totals` summing the visible groups). Credits, 10DLC fees and Verify are always unattributed. `profileId` / `accountId` on their own do not select metering mode: pair them with `range`.  For per-domain consumption *volumes* use `GET /v1/usage/calls` and `GET /v1/usage/sms`. For the billing statement (balance, credits, caps, payment status) use `GET /v1/billing`. 
+  # Dual-mode endpoint, selected by query params, and fully backward compatible:  **Without metering params (the default):** the plan / quota / usage snapshot: plan name, billing period, limits, usage counts, access state. Identical to `GET /v1/usage-stats`. Existing integrations keep working unchanged.  **With `range`, `granularity`, `from`, or `to`:** usage METERING: billed spend (USD) by product family (`accounts`, `numbers`, `calls`, `sms`, `dlc`, `xApi`, `credits`, `other`) over the window, at `day` / `month` / `total` granularity, from the usage-based invoice breakdown (the CHARGE view, which always reconciles with what gets billed). Also served at `GET /v1/usage/daily`. Usage-based accounts only: legacy Stripe accounts get `{ \"supported\": false, \"days\": [] }`.  **Attribution (metering mode):** `groupBy=profile|account` adds an `attribution` breakdown of the window's spend per profile or account, assembled from your own records and pro-rated against the invoice so `sum(groups) + unattributed` equals `totals` exactly. `profileId` / `accountId` instead project the whole payload (`days`, `totals`, `lineItems`) onto that one group; `peaks`, `callUsage` and `tax` are then `null` (team-level facts). Projected `days` spread the group's period share over each day (usage is attributed per period, not per day). Profile-scoped API keys and members only see their profiles' groups (`attribution.restricted: true`, with `totals` summing the visible groups). Credits, 10DLC fees and Verify are always unattributed. `profileId` / `accountId` on their own do not select metering mode: pair them with `range`.  For per-domain consumption *volumes* use `GET /v1/usage/calls` and `GET /v1/usage/sms`. For the billing statement (balance, credits, caps, payment status) use `GET /v1/billing`. 
   # @param [Hash] opts the optional parameters
   # @option opts [Boolean] :reconcile Snapshot mode only. For Stripe subscription users, `true` forces a subscription reconciliation pass even when cached plan data looks complete. 
   # @option opts [String] :range Window to report. `cycle` / `prev-cycle` resolve to the customer's real billing-period bounds (falling back to a trailing 30 days when no invoice exists yet); `7d`…`12mo` are trailing windows; `custom` uses `from` / `to`. 
   # @option opts [Date] :from Inclusive start (UTC date). Required when `range=custom`.
   # @option opts [Date] :to Inclusive end (UTC date). Required when `range=custom`. Max span 366 days.
-  # @option opts [String] :granularity Bucketing of the `days` series: `day` (one row per UTC day), `month` (one row per calendar month, dated to the 1st), or `total` (no series — read `totals`). Does not affect `totals`. 
+  # @option opts [String] :granularity Bucketing of the `days` series: `day` (one row per UTC day), `month` (one row per calendar month, dated to the 1st), or `total` (no series, read `totals`). Does not affect `totals`. 
   # @option opts [String] :group_by Metering mode. Adds `attribution`: the window's spend split per profile or per account (keys are ids; resolve names via `GET /v1/profiles` / `GET /v1/accounts`).
-  # @option opts [String] :profile_id Metering mode (pair with `range`). Project the payload onto this profile's attributed share. Mutually exclusive with `accountId`, and `groupBy` (if given) must be `profile`; 404 when the profile is not in your workspace (or outside a scoped key's profiles).
+  # @option opts [String] :profile_id Metering mode (pair with `range`). Project the payload onto this profile's attributed share. Mutually exclusive with `accountId`, and `groupBy` (if given) must be `profile`; 404 when the profile is not in your team (or outside a scoped key's profiles).
   # @option opts [String] :account_id Metering mode (pair with `range`). Project the payload onto this account's attributed share. Mutually exclusive with `profileId`, and `groupBy` (if given) must be `account`; 404 when the account is not visible to the caller.
   # @return [GetUsage200Response]
   describe 'get_usage test' do
@@ -95,7 +95,7 @@ describe 'UsageApi' do
 
   # unit tests for get_usage_stats
   # Get plan and usage snapshot (plan, limits, payment status)
-  # The plan / quota / payment-status snapshot: current plan name, billing period, plan limits, usage counts, and access state. Identical to a bare `GET /v1/usage` call (this path is its deprecated alias). For billed spend by product, call `GET /v1/usage` with `range` / `granularity` params. The statement view (balance, credits, caps, payment status) lives at `GET /v1/billing`.  The response shape depends on the account's `billingSystem`:   * Stripe users: per-period `usage.uploads` / `usage.profiles` counters.   * Metronome (usage-based) users: `usage.connectedAccounts`,     `usage.xApiCallsByOperation` (per-operation X API call counts —     resolve keys via `GET /v1/billing/x-pricing`), plus a `spend`     block with `currentPeriodCents`, `xSpendCents`, and     `xSpendLimitCents`. The legacy `usage.xApiCalls` 3-tier     aggregate is still emitted for back-compat but excludes the     $0.200 URL tier and any future tiers — new clients should     consume `xApiCallsByOperation` only. 
+  # The plan / quota / payment-status snapshot: current plan name, billing period, plan limits, usage counts, and access state. Identical to a bare `GET /v1/usage` call (this path is its deprecated alias). For billed spend by product, call `GET /v1/usage` with `range` / `granularity` params. The statement view (balance, credits, caps, payment status) lives at `GET /v1/billing`.  The response shape depends on the account's `billingSystem`:   * Stripe users: per-period `usage.uploads` / `usage.profiles` counters.   * Usage-based billing users: `usage.connectedAccounts`,     `usage.xApiCallsByOperation` (per-operation X API call counts;     resolve keys via `GET /v1/billing/x-pricing`), plus a `spend`     block with `currentPeriodCents`, `xSpendCents`, and     `xSpendLimitCents`. The legacy `usage.xApiCalls` 3-tier     aggregate is still emitted for back-compat but excludes the     $0.200 URL tier and any future tiers, so new clients should     consume `xApiCallsByOperation` only. 
   # @param [Hash] opts the optional parameters
   # @option opts [Boolean] :reconcile For Stripe subscription users, `true` forces a subscription reconciliation pass even when cached plan data looks complete. Omit the parameter, or pass `false`, to use the default first-time-only reconciliation behavior. Invalid boolean values are rejected. 
   # @return [UsageStats]
@@ -106,8 +106,8 @@ describe 'UsageApi' do
   end
 
   # unit tests for get_x_api_pricing
-  # Get X/Twitter API pricing table
-  # Returns Zernio's canonical X/Twitter API pricing table. Each X action has its own Metronome product and its own rate, and Zernio passes X API costs through at exact rates with zero markup.  The response is identical for every authenticated user (pricing is universal), so it is safe to cache on the client for the duration of a billing period.  To compute your own per-operation spend, pair this endpoint with `GET /v1/usage-stats` — that endpoint returns `usage.xApiCallsByOperation` keyed by the same `operation` field you get here. 
+  # Get X API pricing table
+  # Returns Zernio's canonical X API pricing table. Each X action has its own billing product and its own rate, and Zernio passes X API costs through at exact rates with zero markup.  The response is identical for every authenticated user (pricing is universal), so it is safe to cache on the client for the duration of a billing period.  To compute your own per-operation spend, pair this endpoint with `GET /v1/usage-stats`, which returns `usage.xApiCallsByOperation` keyed by the same `operation` field you get here. 
   # @param [Hash] opts the optional parameters
   # @return [XApiPricing]
   describe 'get_x_api_pricing test' do

data/spec/api/users_api_spec.rb

@@ -46,7 +46,7 @@ describe 'UsersApi' do
 
   # unit tests for list_users
   # List users
-  # Returns all users in the workspace including roles and profile access. Also returns the currentUserId of the caller.
+  # Returns all users in the team including roles and profile access. Also returns the currentUserId of the caller.
   # @param [Hash] opts the optional parameters
   # @return [ListUsers200Response]
   describe 'list_users test' do

data/spec/api/validate_api_spec.rb

@@ -58,7 +58,7 @@ describe 'ValidateApi' do
 
   # unit tests for validate_post_length
   # Validate character count
-  # Check weighted character count per platform and whether the text is within each platform's limit.  Twitter/X uses weighted counting (URLs = 23 chars via t.co, emojis = 2 chars). All other platforms use plain character length.  Returns counts and limits for all 15 supported platform variants.  X (Twitter) returns two rows and this endpoint cannot tell you which one applies to you: it takes only `text`, so it never resolves an account. `twitter` (280) is the free tier limit. `twitterPremium` (25000) applies only when the target X account has a paid X subscription, and publishing enforces 280 instead for any post carrying a poll (this endpoint has no poll input, so the `twitterPremium` row always shows 25000). A free account trusting the `twitterPremium` row can pass validation here and still fail at publish time, where the account's real limit is enforced.  To validate against the per-account limit, use `POST /v1/tools/validate/post` instead: it accepts an `accountId` per platform entry, resolves X Premium status, and checks the text against the limit publishing enforces, including the poll cap. A missing, foreign, or invalid `accountId` falls back to the conservative 280. 
+  # Check weighted character count per platform and whether the text is within each platform's limit.  X uses weighted counting (URLs = 23 chars via t.co, emojis = 2 chars). All other platforms use plain character length.  Returns counts and limits for all 15 supported platform variants.  X returns two rows and this endpoint cannot tell you which one applies to you: it takes only `text`, so it never resolves an account. `twitter` (280) is the free tier limit. `twitterPremium` (25000) applies only when the target X account has a paid X subscription, and publishing enforces 280 instead for any post carrying a poll (this endpoint has no poll input, so the `twitterPremium` row always shows 25000). A free account trusting the `twitterPremium` row can pass validation here and still fail at publish time, where the account's real limit is enforced.  To validate against the per-account limit, use `POST /v1/tools/validate/post` instead: it accepts an `accountId` per platform entry, resolves X Premium status, and checks the text against the limit publishing enforces, including the poll cap. A missing, foreign, or invalid `accountId` falls back to the conservative 280. 
   # @param validate_post_length_request 
   # @param [Hash] opts the optional parameters
   # @return [ValidatePostLength200Response]
@@ -73,7 +73,7 @@ describe 'ValidateApi' do
   # Check if a subreddit exists and return basic info (title, subscriber count, NSFW status, post types allowed).  When accountId is provided, uses authenticated Reddit OAuth API with automatic token refresh (recommended). Falls back to Reddit's public JSON API, which may be unreliable from server IPs. Returns exists: false for private, banned, or nonexistent subreddits. 
   # @param name Subreddit name (with or without \"r/\" prefix)
   # @param [Hash] opts the optional parameters
-  # @option opts [String] :account_id Reddit social account ID for authenticated lookup (recommended for reliable results)
+  # @option opts [String] :account_id Reddit account ID for authenticated lookup (recommended for reliable results)
   # @return [ValidateSubreddit200Response]
   describe 'validate_subreddit test' do
     it 'should work' do

data/spec/api/verify_api_spec.rb

@@ -34,7 +34,7 @@ describe 'VerifyApi' do
 
   # unit tests for check_verification
   # Check a verification code
-  # Verify the code the user typed. Wrong, expired, and exhausted codes answer 200 with `valid: false` and the settled `status` — only an unknown id is a 404. A correct code consumes the verification (single-use, `status: approved`) and fires the `verification.approved` webhook; the 5th wrong attempt settles it as `max_attempts_reached` and fires `verification.failed`. 
+  # Verify the code the user typed. Wrong, expired, and exhausted codes answer 200 with `valid: false` and the settled `status`. Only an unknown id is a 404. A correct code consumes the verification (single-use, `status: approved`) and fires the `verification.approved` webhook; the 5th wrong attempt settles it as `max_attempts_reached` and fires `verification.failed`. 
   # @param verification_id 
   # @param check_verification_request 
   # @param [Hash] opts the optional parameters