Skip to content

Per-Connector Template Rendering #73

Description

@tsutomi

"WhatsApp wants a template name and parameters. SendGrid wants a template ID. The framework should speak both."

The Problem Today

Providers that have their own server-side template systems (WhatsApp Business, SendGrid, Firebase) expect the template to be referenced by a provider-specific identifier and delivered in a provider-specific format. There is no bridge between the framework's template model and these provider-native systems.

What We Are Building

Per-connector template adapters that, when a connector detects that a message references a template, determine whether to: (a) delegate to the provider's own template system (passing the provider-native template ID and variable parameters), or (b) render locally via the variable substitution engine and send the rendered content. Each connector's template adapter is configurable — teams that manage their own templates in the provider's console can map framework template names to provider template IDs.

Benefits

  • Provider-managed templates (WhatsApp approved templates, SendGrid dynamic templates) are used natively when available
  • Locally-defined templates are rendered and sent as regular content for providers without server-side templating
  • The template reference in the message is the same regardless of which path is taken

Metadata

Metadata

Assignees

No one assigned

    Labels

    No fields configured for Feature.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions