Behind the scenes
Not every module is a widget. Four of them do their work server-side once the embeds hand something off. Submitting the form on the Contact page walks this whole pipeline for real on the blueprint tenant.
What one form submission triggers
- 1
Spam scoring + storage — forms module
Honeypot, fill-time trap, and content heuristics score the submission. Spam is stored for review but never notified. - 2
Email notification — email module (SES)
The worker sends the full submission to the tenant's notification addresses over the tenant's verified sending domain, with reply-to set to the visitor. - 3
Text notification — sms module (Twilio)
A trimmed two-segment version (who, how to reach them, a bite of the message) goes to the configured phones. - 4
Analytics event — analytics module
The widget tracks form_submit, so conversions sit next to traffic in the dashboards. - 5
Monthly report — report module
On the 1st, the tenant's report email totals the month: leads, emails, texts, review clicks, traffic. - 6
Domain & DNS — site module
Not part of the request path at all: it manages the customer domain and DNS records at Hostinger from mpf-admin, including this site's own subdomain.
Why there's nothing to embed here
These modules are deliberately invisible to the customer site — they ride the queue on the platform's worker, so a slow SMTP relay or a carrier hiccup can never add a millisecond to a page or a form submission. Verifying them is what the blueprint tenant is for: submit the contact form, then check your inbox, your phone, the audit log, and the Analytics tab.