Problem or Use Case
Summary
The WhatsApp Cloud API docs note that message-template support is "not yet
implemented in Hermes ... planned but waiting on a clear demand signal." This
issue is that demand signal, from a real production use case.
Use case
I run an engine-machining business in Mexico City and I'm building a
customer-facing WhatsApp agent on Hermes (Cloud API adapter). The core of my
business is re-engaging leads who asked for a quote but went quiet — a follow-up
days or weeks later is often what converts them into a shop visit.
Meta's 24-hour customer-service window makes this impossible with free-form
messages: any outbound sent more than 24h after the customer's last message is
rejected (error 131047) unless it's a pre-approved template. So template support
isn't a nice-to-have for my use case — it's the single feature that the entire
re-engagement half of the business depends on.
What I'm asking for
First-class support in the whatsapp_cloud adapter for sending pre-approved
Meta message templates, ideally:
- A way for the agent (or a scheduled job) to send a named template with
parameters to a given recipient.
- Handling of the template-specific payload (
type: "template", template name,
language, components/variables).
- Graceful surfacing of Meta's template-related errors.
Current workaround
For now I can send templates from a separate process that POSTs directly to the
Graph API with the same phone number credentials, while Hermes owns the inbound
webhook. It works, but it means running a second system just for the one thing
Hermes can't do yet — native support would let me retire that entirely.
Why this matters beyond me
Any business using Hermes for customer-facing WhatsApp will hit the same 24h wall
the moment they want to follow up with a customer who didn't reply same-day.
Re-engagement is core to most real sales workflows, not an edge case.
Thanks for the great work on the Cloud API adapter — the rest of it fits my use
case really well.
Proposed Solution
I'll describe the behavior from a user's perspective and leave the exact
implementation to the maintainers, since you know the adapter's internals far
better than I do.
Desired behavior: the agent (or a scheduled job) can send a pre-approved
Meta template to a specific recipient — used when it needs to reach someone
outside the 24h window, where free-form text is rejected.
What a call would need to express:
- recipient (wa_id)
- template name
- language code
- the template's variable values (body parameters, and header/button params if
the template uses them)
How it might fit (suggestions, not prescriptions):
- Conceptually it mirrors the existing outbound text path that already POSTs to
the Graph API — same endpoint (/<phone_id>/messages), same auth, just
type: "template" instead of type: "text".
- Exposed to the agent as an outbound capability/tool it can invoke when
appropriate, so a re-engagement template can be sent as part of a scheduled
follow-up.
- Template errors from Meta (e.g. 131047 re-engagement, 132xxx template errors)
surfaced clearly rather than failing silently, so the operator knows a
follow-up didn't land.
I don't want to over-specify your internals — the key need is that templates
become a first-class outbound type the agent can use, however that's cleanest in
your design.
Alternatives Considered
1. Send templates from a separate process (current workaround).
A small external sender (or an existing n8n instance) POSTs templates directly
to the Graph API using the same phone number credentials, while Hermes owns the
inbound webhook. This works and is what I'll use in the meantime. The downside:
it means running and maintaining a second system purely for the one thing the
adapter can't do yet. Native support would let me retire it entirely and keep a
single source of truth for the conversation.
2. Stay entirely within the 24h window (no late re-engagement).
Design the bot to only ever reply inside the window and never follow up later.
This avoids the problem but defeats the core of my use case — the follow-up days
or weeks later is precisely what converts quiet leads into shop visits. Not a
real option for a sales workflow.
3. Put an orchestrator (n8n) in front of Hermes as the webhook owner.
Let an external system own the Meta webhook and forward conversations into
Hermes. I ruled this out: the Cloud adapter verifies Meta's X-Hub-Signature-256
against the exact raw request body, so any orchestrator that re-parses and
re-serializes the payload breaks signature verification. Making it work would
reduce the orchestrator to a transparent proxy and still leave two sources of
conversational state. It recreates the exact fragility I'm trying to move away
from.
Why native template support is better than all of these: it keeps Hermes as
the single owner of the WhatsApp channel — one webhook, one conversation state,
one system — and removes the only reason I currently need a second moving part.
Feature Type
Gateway / messaging improvement
Scope
None
Contribution
Debug Report (optional)
Problem or Use Case
Summary
The WhatsApp Cloud API docs note that message-template support is "not yet
implemented in Hermes ... planned but waiting on a clear demand signal." This
issue is that demand signal, from a real production use case.
Use case
I run an engine-machining business in Mexico City and I'm building a
customer-facing WhatsApp agent on Hermes (Cloud API adapter). The core of my
business is re-engaging leads who asked for a quote but went quiet — a follow-up
days or weeks later is often what converts them into a shop visit.
Meta's 24-hour customer-service window makes this impossible with free-form
messages: any outbound sent more than 24h after the customer's last message is
rejected (error 131047) unless it's a pre-approved template. So template support
isn't a nice-to-have for my use case — it's the single feature that the entire
re-engagement half of the business depends on.
What I'm asking for
First-class support in the
whatsapp_cloudadapter for sending pre-approvedMeta message templates, ideally:
parameters to a given recipient.
type: "template", template name,language, components/variables).
Current workaround
For now I can send templates from a separate process that POSTs directly to the
Graph API with the same phone number credentials, while Hermes owns the inbound
webhook. It works, but it means running a second system just for the one thing
Hermes can't do yet — native support would let me retire that entirely.
Why this matters beyond me
Any business using Hermes for customer-facing WhatsApp will hit the same 24h wall
the moment they want to follow up with a customer who didn't reply same-day.
Re-engagement is core to most real sales workflows, not an edge case.
Thanks for the great work on the Cloud API adapter — the rest of it fits my use
case really well.
Proposed Solution
I'll describe the behavior from a user's perspective and leave the exact
implementation to the maintainers, since you know the adapter's internals far
better than I do.
Desired behavior: the agent (or a scheduled job) can send a pre-approved
Meta template to a specific recipient — used when it needs to reach someone
outside the 24h window, where free-form text is rejected.
What a call would need to express:
the template uses them)
How it might fit (suggestions, not prescriptions):
the Graph API — same endpoint (
/<phone_id>/messages), same auth, justtype: "template"instead oftype: "text".appropriate, so a re-engagement template can be sent as part of a scheduled
follow-up.
surfaced clearly rather than failing silently, so the operator knows a
follow-up didn't land.
I don't want to over-specify your internals — the key need is that templates
become a first-class outbound type the agent can use, however that's cleanest in
your design.
Alternatives Considered
1. Send templates from a separate process (current workaround).
A small external sender (or an existing n8n instance) POSTs templates directly
to the Graph API using the same phone number credentials, while Hermes owns the
inbound webhook. This works and is what I'll use in the meantime. The downside:
it means running and maintaining a second system purely for the one thing the
adapter can't do yet. Native support would let me retire it entirely and keep a
single source of truth for the conversation.
2. Stay entirely within the 24h window (no late re-engagement).
Design the bot to only ever reply inside the window and never follow up later.
This avoids the problem but defeats the core of my use case — the follow-up days
or weeks later is precisely what converts quiet leads into shop visits. Not a
real option for a sales workflow.
3. Put an orchestrator (n8n) in front of Hermes as the webhook owner.
Let an external system own the Meta webhook and forward conversations into
Hermes. I ruled this out: the Cloud adapter verifies Meta's
X-Hub-Signature-256against the exact raw request body, so any orchestrator that re-parses and
re-serializes the payload breaks signature verification. Making it work would
reduce the orchestrator to a transparent proxy and still leave two sources of
conversational state. It recreates the exact fragility I'm trying to move away
from.
Why native template support is better than all of these: it keeps Hermes as
the single owner of the WhatsApp channel — one webhook, one conversation state,
one system — and removes the only reason I currently need a second moving part.
Feature Type
Gateway / messaging improvement
Scope
None
Contribution
Debug Report (optional)