Viresso sends transactional API emails, form-answer emails, and platform notifications.
How email is sent
The MAIL_MAILER setting selects the delivery transport. Configured transports include Resend, SMTP, SES, Mailgun, Postmark, and log. The example local environment uses log, which writes messages to the application log instead of delivering them. An existing installation may use a different transport; local mode does not override it.
The default sender is controlled by MAIL_FROM_ADDRESS and MAIL_FROM_NAME (info@viresso.com and Viresso in the example environment).
API email from address
Emails sent through the API use a workspace-specific from address based on the workspace name.
Notification email from address
Platform notifications and form-answer emails use the platform’s default from address.
Transactional email API
The Email API sends transactional emails. See the Email API reference for complete documentation.
Form-answer emails
In Forms → Settings, set Submit action to Send to workspace email or Send to custom email. The workspace option uses the current email in Settings → General and shows the destination in an info alert. The custom option requires one valid recipient address; the recipient does not need a Viresso account.
Each accepted answer is saved and emailed with the form title, answer ID, question labels, and validated values. Invalid submissions do not send email, and replaying the same submission token does not send it twice. The visitor's success message or redirect is configured separately.
Form emails are controlled by the form's submit action, independently of workspace and personal notification toggles. Switch to Save answer only to stop sending them. See Forms.
Delivery and queues
Form-answer notifications are queued after the answer is saved. With an asynchronous queue such as database or redis, a worker must be running:
php artisan queue:work
With QUEUE_CONNECTION=sync, the notification runs during the request. With MAIL_MAILER=log, processing the notification writes it to the log and does not send an email. Check the queue worker, mail transport, and application/failed-job logs when an answer is saved but no email arrives. A successful form submission confirms the answer was saved; it does not confirm inbox delivery.
Notification emails
The platform sends email notifications for the following events:
| Notification | When it is sent |
|---|---|
| Member added | A user is added to the workspace |
| Member removed | A user is removed from the workspace |
| Role changed | A user's role is changed |
| Suspension changed | The workspace is suspended or restored |
| Invoice ready | A new invoice is generated |
| Payment reminder | An invoice is unpaid or overdue |
| Webhook delivery | A webhook succeeds or fails |
| Comment mention | A user is mentioned in a comment |
| New user created | A new user account is registered |
| User deleted | A user account is deleted |
| Feedback received | A user submits feedback |
| Daily workspace updates | Daily activity summary |
Notification toggles
Workspace administrators can control which notification emails are sent from Settings → Notifications:
| Toggle | Controls |
|---|---|
| Email Notifications | Master toggle for optional workspace notification emails. Billing and account security emails are still sent. |
| Workspace Access | Emails about member changes (added, removed, role changed) |
| Webhook Dispatches | Emails about webhook delivery results |
User notification preferences
Each user can control their personal notification preferences from Account → Notifications:
| Preference | Description |
|---|---|
| Email Notifications | Receive email notifications |
| Comment Notifications | Receive notifications when mentioned in comments |
| Access Notifications | Receive notifications about workspace access changes |
Related pages
- Email API — Sending email through the API.
- Workspace Settings — Managing notification toggles.
- API Access — API key authentication.