planvortex 0.16.0__tar.gz → 0.17.0__tar.gz

{planvortex-0.16.0 → planvortex-0.17.0}/CHANGELOG.md

@@ -4,6 +4,32 @@ All notable changes to this package are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to
 [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.17.0] - 2026-10-28
+
+### Added
+
+- **`message_echoes` webhook event (WhatsApp).** When a WhatsApp number is also used in the
+  WhatsApp Business app on a phone, what the business sends from the app arrives as
+  `field: "message_echoes"`, with the message in `messageObj` as one of **ours**: `contact_id` is
+  the person it was sent to and `from_contact_id` is absent. New type `MessageEchoChange` and
+  predicate `is_message_echo_change()`. It is deliberately **not** part of `is_message_change()`: a
+  bot that answers every incoming message must not answer the business itself. Store it, do not
+  reply.
+- **`edit_date` and `deleted_date` on messages.** A contact edited or deleted the message on
+  WhatsApp. An edited message already carries the new text; a deleted one has no text and no files.
+  No webhook event is sent for either: the message itself changes.
+- **`unsupported_message`** in the message types: a WhatsApp message the API cannot show (a voice
+  note, a document, a sticker, or a type WhatsApp does not let the API read). It only ever arrives,
+  keeps the caption as `text` when there is one, and sending one is refused.
+
+## [0.16.1] - 2026-10-25
+
+### Changed
+
+- The README has a **Guides** section with the longer write-ups on planvortex.com: publishing to
+  social media from Python, why a Meta access token lasts 60 days and how to refresh it, character
+  limits across social APIs, what posting on X costs, and LinkedIn API access. No code changed.
+
 ## [0.16.0] - 2026-10-15
 
 ### Added

{planvortex-0.16.0 → planvortex-0.17.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: planvortex
-Version: 0.16.0
+Version: 0.17.0
 Summary: Official Python client for the PlanVortex API
 Project-URL: Homepage, https://planvortex.com/en/developers
 Project-URL: Documentation, https://taliasoftworks.github.io/PlanVortexPython/
@@ -407,6 +407,17 @@ Five runnable scripts, each one the whole of its path and with a test of its own
 `comments.py` only reads unless you set `PLANVORTEX_ALLOW_REPLY=1`: replying is public, immediate,
 and reaches a person.
 
+## Guides
+
+Longer write-ups on planvortex.com:
+
+- [Publishing to social media from Python without building one integration per network](https://planvortex.com/en/resources/publish-social-media-python)
+- [Meta access token expired? Why it lasts 60 days and how to refresh it](https://planvortex.com/en/resources/meta-access-token-expiry)
+- [Character limits across social APIs: .length lies, and it lies both ways](https://planvortex.com/en/resources/social-media-character-limits)
+- [How much does it cost to post on X with the API in 2026](https://planvortex.com/en/resources/x-api-pricing-2026)
+- [Is the LinkedIn API free? Pricing and posting access in 2026](https://planvortex.com/en/resources/linkedin-api-pricing-access)
+- [All articles](https://planvortex.com/en/resources)
+
 ## Links
 
 - [Reference](https://taliasoftworks.github.io/PlanVortexPython/)

{planvortex-0.16.0 → planvortex-0.17.0}/README.md

@@ -377,6 +377,17 @@ Five runnable scripts, each one the whole of its path and with a test of its own
 `comments.py` only reads unless you set `PLANVORTEX_ALLOW_REPLY=1`: replying is public, immediate,
 and reaches a person.
 
+## Guides
+
+Longer write-ups on planvortex.com:
+
+- [Publishing to social media from Python without building one integration per network](https://planvortex.com/en/resources/publish-social-media-python)
+- [Meta access token expired? Why it lasts 60 days and how to refresh it](https://planvortex.com/en/resources/meta-access-token-expiry)
+- [Character limits across social APIs: .length lies, and it lies both ways](https://planvortex.com/en/resources/social-media-character-limits)
+- [How much does it cost to post on X with the API in 2026](https://planvortex.com/en/resources/x-api-pricing-2026)
+- [Is the LinkedIn API free? Pricing and posting access in 2026](https://planvortex.com/en/resources/linkedin-api-pricing-access)
+- [All articles](https://planvortex.com/en/resources)
+
 ## Links
 
 - [Reference](https://taliasoftworks.github.io/PlanVortexPython/)

{planvortex-0.16.0 → planvortex-0.17.0}/openapi/planvortex.openapi.json

@@ -12669,7 +12669,7 @@
           "webhooks"
         ],
         "summary": "A change happened (notification to your app)",
-        "description": "PlanVortex `POST`s to the `webhook_url` of your client app when something happens. **The body is an array of changes**, and each one carries `field` telling you what it is — switch on it and ignore what you do not handle, because the list grows with the product.\n\nThree shapes travel in that array. A change on an **account** (`WebhookChange`) always carries `id_account`, `id_organization` and `social_network`. A change on an **integration** (`IntegrationWebhookChange`) and the end of an **AI plan** (`AiPlanWebhookChange`) carry none of those, because they hang off the organization and not off any account.\n\nThe events delivered today are `new_account`, `change_state_account`, `messages`, `messaging_postbacks`, `messaging_seen`, `messaging_error`, `comments`, `integration_error`, `ai_plan_generated` and `ai_plan_failed`.\n\n### Comments\n\n`field: \"comments\"` is the one for this section, and the comment itself travels in **`commentObj`** — a property of its own, never in `messageObj`. That is deliberate: a comment is not a message, it has no contact and it hangs off a publication. A consumer that only understands messages sees `commentObj` as absent and ignores the change, which is exactly what should happen.\n\n**Which networks arrive this way:** Facebook and Instagram, because Meta pushes them. YouTube, LinkedIn and Google Business have no comment webhook, so those are polled by a background job and appear in the inbox within a few hours rather than instantly. X is polled too, and only when the organization turns it on, because reading replies there is billed per unit.\n\n**Meta repeats deliveries.** The same comment can arrive more than once; the backend is idempotent about it and so should you be — deduplicate on `commentObj.external_id`.\n\n### AI plans\n\n`ai_plan_generated` and `ai_plan_failed` say that a plan has **finished**: it was generated, or it gave up. Instead of polling the plan every few seconds, wait for one of these and then read it once with `GET /clients/{id_client}/organizations/{id_organization}/ai_plans/{id_ai_plan}`. The change carries ids and numbers only, never the prompt or the generated text, so the publications are in that `GET`.\n\nA plan that hits a transient error goes back to the queue and is retried. That is not an end and sends nothing, so each plan sends **one** of these two events, never a `failed` followed by a `generated`. A plan generated with notices (`warnings` above zero) is still `ai_plan_generated`: it is usable, and the notices are in the plan.\n\nThe event goes to **every** app of the client that has a `webhook_url`, not only to the one that created the plan. And it is not retried: if your endpoint was down when the plan finished, the `GET` still tells you how it ended, so on startup read the plans you were waiting for.\n\n### Verifying the signature\n\nEvery delivery carries the body signed with your app's secret, twice:\n\n- `x-hub-signature`: `sha1=<hmac>`\n- `x-hub-signature-256`: `sha256=<hmac>`\n\nCompute the HMAC over the **raw** request body — not over a re-serialized copy of the parsed JSON — and compare in constant time. Prefer the sha256 header.\n\nDelivery is best effort: PlanVortex does not retry a webhook that fails.",
+        "description": "PlanVortex `POST`s to the `webhook_url` of your client app when something happens. **The body is an array of changes**, and each one carries `field` telling you what it is — switch on it and ignore what you do not handle, because the list grows with the product.\n\nThree shapes travel in that array. A change on an **account** (`WebhookChange`) always carries `id_account`, `id_organization` and `social_network`. A change on an **integration** (`IntegrationWebhookChange`) and the end of an **AI plan** (`AiPlanWebhookChange`) carry none of those, because they hang off the organization and not off any account.\n\nThe events delivered today are `new_account`, `change_state_account`, `messages`, `messaging_postbacks`, `messaging_seen`, `messaging_error`, `message_echoes`, `comments`, `integration_error`, `ai_plan_generated` and `ai_plan_failed`.\n\n### Comments\n\n`field: \"comments\"` is the one for this section, and the comment itself travels in **`commentObj`** — a property of its own, never in `messageObj`. That is deliberate: a comment is not a message, it has no contact and it hangs off a publication. A consumer that only understands messages sees `commentObj` as absent and ignores the change, which is exactly what should happen.\n\n**Which networks arrive this way:** Facebook and Instagram, because Meta pushes them. YouTube, LinkedIn and Google Business have no comment webhook, so those are polled by a background job and appear in the inbox within a few hours rather than instantly. X is polled too, and only when the organization turns it on, because reading replies there is billed per unit.\n\n**Meta repeats deliveries.** The same comment can arrive more than once; the backend is idempotent about it and so should you be — deduplicate on `commentObj.external_id`.\n\n### AI plans\n\n`ai_plan_generated` and `ai_plan_failed` say that a plan has **finished**: it was generated, or it gave up. Instead of polling the plan every few seconds, wait for one of these and then read it once with `GET /clients/{id_client}/organizations/{id_organization}/ai_plans/{id_ai_plan}`. The change carries ids and numbers only, never the prompt or the generated text, so the publications are in that `GET`.\n\nA plan that hits a transient error goes back to the queue and is retried. That is not an end and sends nothing, so each plan sends **one** of these two events, never a `failed` followed by a `generated`. A plan generated with notices (`warnings` above zero) is still `ai_plan_generated`: it is usable, and the notices are in the plan.\n\nThe event goes to **every** app of the client that has a `webhook_url`, not only to the one that created the plan. And it is not retried: if your endpoint was down when the plan finished, the `GET` still tells you how it ended, so on startup read the plans you were waiting for.\n\n### WhatsApp replies sent from the phone\n\nA WhatsApp number can work in the **WhatsApp Business app** on a phone and in PlanVortex at the same time. What the business sends from the app arrives as `field: \"message_echoes\"`, with the message in `messageObj` as one of **ours**: `contact_id` is the person it was sent to and `from_contact_id` is absent. Store it in the thread; do not answer it. It does not open WhatsApp's 24-hour window.\n\nWhen a contact edits or deletes a message, no event is sent: the message itself changes, and the next read returns it with `edit_date` or `deleted_date`.\n\n### Verifying the signature\n\nEvery delivery carries the body signed with your app's secret, twice:\n\n- `x-hub-signature`: `sha1=<hmac>`\n- `x-hub-signature-256`: `sha256=<hmac>`\n\nCompute the HMAC over the **raw** request body — not over a re-serialized copy of the parsed JSON — and compare in constant time. Prefer the sha256 header.\n\nDelivery is best effort: PlanVortex does not retry a webhook that fails.",
         "operationId": "onCommentsWebhook",
         "requestBody": {
           "required": true,
@@ -14186,7 +14186,7 @@
           },
           "webhook_url": {
             "type": "string",
-            "description": "Where PlanVortex posts events, when one is configured.\n\n**The body is an array of changes, not a single object**, and it carries two signature headers computed with this app's secret over the **raw** body: `x-hub-signature` (`sha1=<hex>`) and `x-hub-signature-256` (`sha256=<hex>`). Verify against the bytes you received — parsing the JSON and re-serialising it changes them and the signature will not match.\n\nThe events delivered today are `new_account`, `change_state_account`, `messages`, `messaging_postbacks`, `messaging_seen`, `messaging_error`, `comments`, `integration_error`, `ai_plan_generated` and `ai_plan_failed`. The payload is documented in the `comments` specification. **Every** app of the client that has a `webhook_url` receives every event, not only the app whose call caused it: with two apps, each event arrives twice. Delivery is best effort: PlanVortex does not retry a webhook that fails."
+            "description": "Where PlanVortex posts events, when one is configured.\n\n**The body is an array of changes, not a single object**, and it carries two signature headers computed with this app's secret over the **raw** body: `x-hub-signature` (`sha1=<hex>`) and `x-hub-signature-256` (`sha256=<hex>`). Verify against the bytes you received — parsing the JSON and re-serialising it changes them and the signature will not match.\n\nThe events delivered today are `new_account`, `change_state_account`, `messages`, `messaging_postbacks`, `messaging_seen`, `messaging_error`, `message_echoes`, `comments`, `integration_error`, `ai_plan_generated` and `ai_plan_failed`. The payload is documented in the `comments` specification. **Every** app of the client that has a `webhook_url` receives every event, not only the app whose call caused it: with two apps, each event arrives twice. Delivery is best effort: PlanVortex does not retry a webhook that fails."
           },
           "creation_date": {
             "type": "string",
@@ -15455,7 +15455,7 @@
         "properties": {
           "field": {
             "type": "string",
-            "description": "What kind of change this is. **Treat it as an open list** and ignore what you do not handle: it grows with the product.\n\n- `new_account` / `change_state_account`: an account was connected, or its state changed — it stopped working, its token was refreshed, it was disconnected. On `telegram` this is the **only** way to hear about a connection: there is no callback there, so no request of yours ever returns that account.\n- `messages`: a message came in. It travels in `messageObj`.\n- `messaging_postbacks`: the contact pressed a button or a quick reply. Also in `messageObj`.\n- `messaging_seen`: the contact read the conversation. `messageObj` carries the message they read, when we still have it.\n- `messaging_error`: the network refused a message we sent. The reason is in `messageObj.message_errors`.\n- `comments`: a comment came in. It travels in `commentObj`, never in `messageObj`.",
+            "description": "What kind of change this is. **Treat it as an open list** and ignore what you do not handle: it grows with the product.\n\n- `new_account` / `change_state_account`: an account was connected, or its state changed — it stopped working, its token was refreshed, it was disconnected. A WhatsApp number disconnected from the WhatsApp Business app (or by Meta, after about 14 days without the phone using the app) arrives here with `error_code` 717. On `telegram` this is the **only** way to hear about a connection: there is no callback there, so no request of yours ever returns that account.\n- `messages`: a message came in. It travels in `messageObj`.\n- `messaging_postbacks`: the contact pressed a button or a quick reply. Also in `messageObj`.\n- `messaging_seen`: the contact read the conversation. `messageObj` carries the message they read, when we still have it.\n- `messaging_error`: the network refused a message we sent. The reason is in `messageObj.message_errors`.\n- `message_echoes`: WhatsApp only, when the number is also used in the **WhatsApp Business app** on a phone. The business replied from the app, and the reply travels in `messageObj` as **our** message (`contact_id` is set, `from_contact_id` is not). It is a separate `field` on purpose: a bot that answers every `messages` must not answer the business itself.\n- `comments`: a comment came in. It travels in `commentObj`, never in `messageObj`.",
             "enum": [
               "new_account",
               "change_state_account",
@@ -15463,6 +15463,7 @@
               "messaging_postbacks",
               "messaging_seen",
               "messaging_error",
+              "message_echoes",
               "comments"
             ]
           },
@@ -16999,6 +17000,16 @@
             "type": "string",
             "description": "Identifier of this message on the network."
           },
+          "edit_date": {
+            "type": "string",
+            "format": "date-time",
+            "description": "When the contact **edited** this message on the network (WhatsApp allows it for 15 minutes). `text` is already the edited text; the original is not kept."
+          },
+          "deleted_date": {
+            "type": "string",
+            "format": "date-time",
+            "description": "When the contact **deleted** this message for everyone (WhatsApp allows it for two days). The message stays in the thread with no `text` and no files."
+          },
           "creation_date": {
             "type": "string",
             "format": "date-time"
@@ -17095,7 +17106,7 @@
       },
       "MessageType": {
         "type": "string",
-        "description": "What kind of message this is. `simple_message` and `file_message` work everywhere; the rest are network-specific shapes.",
+        "description": "What kind of message this is. `simple_message` and `file_message` work everywhere; the rest are network-specific shapes.\n\n`unsupported_message` only ever **arrives**: a WhatsApp message that cannot be shown through the API (a voice note, a document, a sticker, or a type WhatsApp does not let the API read). It carries no files, keeps the caption as `text` when there is one, and may carry the network's reason in `message_errors`. If the number is also in the WhatsApp Business app, the message can be read there. Sending one is refused.",
         "enum": [
           "simple_message",
           "file_message",
@@ -17106,7 +17117,8 @@
           "elements_message",
           "postback_message",
           "template_message",
-          "interactive_message"
+          "interactive_message",
+          "unsupported_message"
         ]
       },
       "MessagesConversation": {

{planvortex-0.16.0 → planvortex-0.17.0}/pyproject.toml

@@ -9,7 +9,7 @@ name = "planvortex"
 # entonces `project.version` desapareceria del pyproject y el paso del workflow de release que
 # compara el tag con la version —que lo lee con `tomllib`— dejaria de encontrarla. Se quedan las dos
 # y las ata `tests/test_packaging.py`, que falla si se separan.
-version = "0.16.0"
+version = "0.17.0"
 description = "Official Python client for the PlanVortex API"
 readme = "README.md"
 requires-python = ">=3.10"

{planvortex-0.16.0 → planvortex-0.17.0}/src/planvortex/_generated/models.py

@@ -574,7 +574,7 @@ class AppsClientApp(TypedDict):
 
     **The body is an array of changes, not a single object**, and it carries two signature headers computed with this app's secret over the **raw** body: `x-hub-signature` (`sha1=<hex>`) and `x-hub-signature-256` (`sha256=<hex>`). Verify against the bytes you received — parsing the JSON and re-serialising it changes them and the signature will not match.
 
-    The events delivered today are `new_account`, `change_state_account`, `messages`, `messaging_postbacks`, `messaging_seen`, `messaging_error`, `comments`, `integration_error`, `ai_plan_generated` and `ai_plan_failed`. The payload is documented in the `comments` specification. **Every** app of the client that has a `webhook_url` receives every event, not only the app whose call caused it: with two apps, each event arrives twice. Delivery is best effort: PlanVortex does not retry a webhook that fails.
+    The events delivered today are `new_account`, `change_state_account`, `messages`, `messaging_postbacks`, `messaging_seen`, `messaging_error`, `message_echoes`, `comments`, `integration_error`, `ai_plan_generated` and `ai_plan_failed`. The payload is documented in the `comments` specification. **Every** app of the client that has a `webhook_url` receives every event, not only the app whose call caused it: with two apps, each event arrives twice. Delivery is best effort: PlanVortex does not retry a webhook that fails.
     """
     creation_date: str
     deleted: bool
@@ -1461,9 +1461,12 @@ MessageType: TypeAlias = Literal[
     "postback_message",
     "template_message",
     "interactive_message",
+    "unsupported_message",
 ]
 """
 What kind of message this is. `simple_message` and `file_message` work everywhere; the rest are network-specific shapes.
+
+`unsupported_message` only ever **arrives**: a WhatsApp message that cannot be shown through the API (a voice note, a document, a sticker, or a type WhatsApp does not let the API read). It carries no files, keeps the caption as `text` when there is one, and may carry the network's reason in `message_errors`. If the number is also in the WhatsApp Business app, the message can be read there. Sending one is refused.
 """
 
 
@@ -4180,6 +4183,14 @@ class Message(TypedDict):
     """
     Identifier of this message on the network.
     """
+    edit_date: NotRequired[str]
+    """
+    When the contact **edited** this message on the network (WhatsApp allows it for 15 minutes). `text` is already the edited text; the original is not kept.
+    """
+    deleted_date: NotRequired[str]
+    """
+    When the contact **deleted** this message for everyone (WhatsApp allows it for two days). The message stays in the thread with no `text` and no files.
+    """
     creation_date: str
 
 
@@ -4197,16 +4208,18 @@ class CommentsWebhookChange(TypedDict):
         "messaging_postbacks",
         "messaging_seen",
         "messaging_error",
+        "message_echoes",
         "comments",
     ]
     """
     What kind of change this is. **Treat it as an open list** and ignore what you do not handle: it grows with the product.
 
-    - `new_account` / `change_state_account`: an account was connected, or its state changed — it stopped working, its token was refreshed, it was disconnected. On `telegram` this is the **only** way to hear about a connection: there is no callback there, so no request of yours ever returns that account.
+    - `new_account` / `change_state_account`: an account was connected, or its state changed — it stopped working, its token was refreshed, it was disconnected. A WhatsApp number disconnected from the WhatsApp Business app (or by Meta, after about 14 days without the phone using the app) arrives here with `error_code` 717. On `telegram` this is the **only** way to hear about a connection: there is no callback there, so no request of yours ever returns that account.
     - `messages`: a message came in. It travels in `messageObj`.
     - `messaging_postbacks`: the contact pressed a button or a quick reply. Also in `messageObj`.
     - `messaging_seen`: the contact read the conversation. `messageObj` carries the message they read, when we still have it.
     - `messaging_error`: the network refused a message we sent. The reason is in `messageObj.message_errors`.
+    - `message_echoes`: WhatsApp only, when the number is also used in the **WhatsApp Business app** on a phone. The business replied from the app, and the reply travels in `messageObj` as **our** message (`contact_id` is set, `from_contact_id` is not). It is a separate `field` on purpose: a bot that answers every `messages` must not answer the business itself.
     - `comments`: a comment came in. It travels in `commentObj`, never in `messageObj`.
     """
     id_account: str

{planvortex-0.16.0 → planvortex-0.17.0}/src/planvortex/_version.py

@@ -12,7 +12,7 @@ from __future__ import annotations
 
 import platform
 
-VERSION = "0.16.0"
+VERSION = "0.17.0"
 
 # Sin barra final, y con el `/v1.0.0` dentro: la version de la API es parte de la ruta, no una
 # cabecera, asi que una `base_url` sin ella da 404 en todo.

{planvortex-0.16.0 → planvortex-0.17.0}/src/planvortex/webhooks.py

@@ -81,6 +81,7 @@ WEBHOOK_EVENTS: tuple[str, ...] = (
     "messaging_postbacks",
     "messaging_seen",
     "messaging_error",
+    "message_echoes",
     "comments",
     "integration_error",
     "ai_plan_generated",
@@ -136,6 +137,24 @@ class MessageChange(AccountWebhookChangeBase):
     """The contact on the other side. A comment has none, which is why it is here and not there."""
 
 
+class MessageEchoChange(AccountWebhookChangeBase):
+    """WhatsApp, when the number is also used in the **WhatsApp Business app** on a phone: the
+    business replied from the app.
+
+    ``messageObj`` is one of **our** messages — ``contact_id`` is the person it was sent to and
+    ``from_contact_id`` is absent — and it arrives populated, like in :class:`MessageChange`.
+
+    It is a separate event on purpose, and :func:`is_message_change` does **not** include it: a bot
+    that answers every incoming message must not answer the business itself. Store it in the thread
+    and that is all. It does not open WhatsApp's 24-hour window.
+    """
+
+    field: Literal["message_echoes"]
+    messageObj: NotRequired[Message]
+    id_contact: NotRequired[str]
+    """The contact the business wrote to."""
+
+
 class CommentChange(AccountWebhookChangeBase):
     """A comment came in.
 
@@ -229,6 +248,7 @@ class UnknownWebhookChange(TypedDict):
 WebhookChange: TypeAlias = (
     AccountStateChange
     | MessageChange
+    | MessageEchoChange
     | CommentChange
     | IntegrationErrorChange
     | AiPlanChange
@@ -257,6 +277,12 @@ def is_message_change(change: WebhookChange) -> TypeGuard[MessageChange]:
     return change["field"] in _MESSAGE_EVENTS
 
 
+def is_message_echo_change(change: WebhookChange) -> TypeGuard[MessageEchoChange]:
+    """The business replied from the WhatsApp Business app on a phone. Not an incoming message: do
+    not reply to it. :func:`is_message_change` does not include it."""
+    return change["field"] == "message_echoes"
+
+
 def is_comment_change(change: WebhookChange) -> TypeGuard[CommentChange]:
     """A comment came in."""
     return change["field"] == "comments"
@@ -517,6 +543,7 @@ __all__ = [
     "CommentChange",
     "IntegrationErrorChange",
     "MessageChange",
+    "MessageEchoChange",
     "RawWebhookBody",
     "UnknownWebhookChange",
     "WebhookAlgorithm",
@@ -530,6 +557,7 @@ __all__ = [
     "is_comment_change",
     "is_integration_error_change",
     "is_message_change",
+    "is_message_echo_change",
     "parse_webhook_body",
     "verify_webhook_signature",
 ]

{planvortex-0.16.0 → planvortex-0.17.0}/tests/test_webhooks.py

@@ -32,6 +32,7 @@ from planvortex.webhooks import (
     CommentChange,
     IntegrationErrorChange,
     MessageChange,
+    MessageEchoChange,
     UnknownWebhookChange,
     WebhookBodyError,
     WebhookChange,
@@ -42,6 +43,7 @@ from planvortex.webhooks import (
     is_comment_change,
     is_integration_error_change,
     is_message_change,
+    is_message_echo_change,
     parse_webhook_body,
     verify_webhook_signature,
 )
@@ -328,6 +330,9 @@ def _cambio(field: str, **extra: Any) -> WebhookChange:
         ("messaging_postbacks", is_message_change),
         ("messaging_seen", is_message_change),
         ("messaging_error", is_message_change),
+        # El eco de WhatsApp (lo que el negocio contesta desde la app) es suyo y NO es un mensaje
+        # que contestar: un bot que filtra por is_message_change no tiene que verlo
+        ("message_echoes", is_message_echo_change),
         ("comments", is_comment_change),
         ("integration_error", is_integration_error_change),
         ("ai_plan_generated", is_ai_plan_change),
@@ -339,6 +344,7 @@ def test_cada_evento_lo_reconoce_su_predicado_y_solo_el_suyo(field: str, predica
     todos = (
         is_account_state_change,
         is_message_change,
+        is_message_echo_change,
         is_comment_change,
         is_integration_error_change,
         is_ai_plan_change,
@@ -517,12 +523,12 @@ def test_lo_que_el_spec_declara_obligatorio_lo_es_en_los_tres(tipo: Any) -> None
     assert set(CUENTA_SPEC["required"]) <= set(tipo.__required_keys__)
 
 
-def test_cada_field_del_spec_cae_en_uno_de_los_tres_tipos() -> None:
+def test_cada_field_del_spec_cae_en_uno_de_los_cuatro_tipos() -> None:
     """El reparto por `field`: ni un evento sin tipo, ni un tipo con un `field` que el spec no
     declara — que es como se colaria un evento inventado con toda la pinta de ser real.
     """
     repartidos: list[str] = []
-    for tipo in (AccountStateChange, MessageChange, CommentChange):
+    for tipo in (AccountStateChange, MessageChange, MessageEchoChange, CommentChange):
         repartidos.extend(get_args(tipo.__annotations__["field"]))
 
     assert sorted(repartidos) == sorted(CUENTA_SPEC["properties"]["field"]["enum"])