Herald
مركز واحد لإرسال البريد الإلكتروني لتطبيقاتك: مفتاح لكل تطبيق، وقوالب، وإرسال جماعي وحملات، وخادم صادر خاص بك، وسجل إرسال، وتحليلات.
One email sending centre for your applications
Herald is the central point that the applications a team runs call when they want to send an email. Each application connects with its own key and hands the email it wants to send to a single endpoint; templates, recipient lists, outgoing server settings and the send history live in one panel. That is where you see what went out and what did not.
The product came out of our own need. In a team running dozens of applications, every product carries its own mail server, its own template and its own error log; when a template changes it is fixed in five places, and when a message fails nobody knows which application tried what from which server. Herald was written to gather that work in one place; today the email of the applications in the family leaves from here.
The channel is email. A single send is attempted immediately and returns its result at once; bulk sends and campaigns are queued, and a failed attempt is retried at growing intervals. Sending needs no account, the application's key and secret are enough; entering the panel uses a Vosetu Passport account.
- A key and secret per application; no account needed
- Sending with a template or with a direct subject and body
- Bulk sends and scheduled campaigns queued, with retries
- A shared or per-application outgoing server; every message's status in the history
The screens of the panel
Applications send, the team manages from the panel. Templates are written here, recipient lists are chosen here, the outgoing server is defined here and a message that did not go is resent from here.
Applications
Registered applications, their keys and descriptions; renewing a key affects one application independently of the others.
Templates
Templates that hold subject and body with variables; shared or per application; the application sends only the template name and the values.
Bulk send
Send one message to a list or to pasted addresses; duplicates are removed, opt-outs skipped, and the result counts are shown.
Campaigns
A recurring send rule built from a segment, a template and an interval; every run recorded with date, reached and skipped counts.
Recipients
A recipient list kept in sync with application users; filters by label, application and last activity; opt-out preference and bounce mark.
Outgoing server
A shared outgoing server or a separate one per application; sender address and name defined separately.
Send history
Application, recipient, subject and status in one list; a row opens the full detail; a failed message is requeued in one click.
Analytics
Total sends, the last day, queued items, daily series, breakdown by status and source, top sending applications, failure rate.
The heart of the flow
The journey of an email
The application is registered in the panel; a key and a secret are generated and shown once. A send request is identified by two headers and carries either a direct subject and body or a template name with variables; if both arrive, the template wins. Herald picks the application's own outgoing server if there is one, otherwise the shared one, and attempts delivery. A single request is attempted immediately and returns its result and message id at once; even if delivery fails later, the status is read from the history.
- Key and secret; an invalid request is rejected
- Direct content or a template name and variables
- File attachments on a single send within a size limit
- Every send, successful or not, is recorded
Templates and variables
A template holds the subject and body with double-brace variables; values are substituted at send time. A placeholder without a value stays as it is, so missing data never silently turns into blank text. A template can be shared or specific to one application; if two carry the same name, the application-specific one wins. A template you change in the panel goes out in its new form on the next send; no code changes in the application. A deactivated template cannot be found by name.
- Shared or per-application templates; the specific one wins
- A variable without a value stays as it is
- In campaigns name and email fill in by themselves
- When a template changes, no code changes in the application
Bulk sends and campaigns
From the panel you write a message and send it to a recipient list. Recipients are picked with filters: subscribers only, users of a particular application, people who have not signed in for a while; or addresses are pasted directly. Duplicates and opt-outs are removed. Large lists are queued; a failed attempt is retried at growing intervals, up to a limit. A campaign ties the same send to a schedule: a segment, a template and an interval are defined, the first run is planned one interval later, and the rest repeats by itself. The date, reached and skipped counts of every run stay on record.
- Filtered recipient selection or pasted addresses
- Duplicates and opt-outs are removed automatically
- Campaign: segment + template + interval; a manual run does not break the schedule
- Run history: date, queued, skipped, error
Delivery and history
The outgoing server is defined with standard mail server fields: address, port, username, password, sender address and name. A shared server serves every application; if a server is defined for one application it takes priority; a deactivated server drops out and sending falls back to an active one. The send history lists every message with application, recipient, subject and status; there are three statuses: queued, sent, failed. A failed message is requeued in one click.
- A shared server or one per application; the specific one wins
- The password is never shown again after saving
- Statuses: queued, sent, failed
- Resend a failed message in one click
The capability catalogue
- A single send endpoint, key and secret per application
- Direct subject and body, or template name and variables
- To, cc and bcc
- Plain-text or HTML body
- File attachments on a single send (size-limited)
- Immediate attempt, message id and status in the response
- Application registration: name, description
- Key and secret shown once
- Key renewal; other applications unaffected
- Personal API keys: read-only / write, expiring or permanent
- Panel sign-in with Vosetu Passport; no local password
- Subject and body with double-brace variables
- Shared or per application; the specific one wins
- A variable without a value stays as it is
- Active / inactive templates
- Bulk send to a list or pasted addresses
- Filters: subscription, application, last sign-in
- Duplicate and opt-out removal; reached / skipped counts
- Queue and retries at growing intervals
- Campaign rule: segment + template + interval
- Run now; run history
- A recipient list in sync with application users
- Filters by label, application and last activity
- Opt-out preference and bounce mark preserved
- Manual add and edit
- Shared or per-application outgoing server
- Send history and full detail
- Requeue a failed message
- Total, last day, queued, daily series
- Breakdown by status and source, top sending applications
- Failure rate
- Brands and branches
- Module market: the sending core is always on
- Subscription status and quotas
- Turkish and English
Setup and packages
Herald runs in the cloud on a subscription: the panel and the sending service are with us, your applications only send requests with their keys. Connecting an application installs nothing on your server; it is called with a plain HTTP request from any language. You define your own mail server as the outgoing server; the sender address and name stay yours.
Packages scale with how many applications you send from and how many emails a month; applications beyond the included number are added for a monthly fee. The entry package covers application credentials, the outgoing server setting and the send history; the team package adds bulk sends, the filtered recipient list, templates, queued sending and the analytics dashboard; the enterprise package brings recurring campaign rules and a wider quota. Every package starts with a free trial that asks for no card; the current list and prices are on the product's own pricing page.
When the monthly email quota is used up, new requests are rejected until the package is upgraded; the state shows on the subscription screen. If the quota check is temporarily unreachable, sending does not stop: a critical message such as a password reset is never cut off because of the quota service.
- Cloud subscription; nothing to install, your own mail server
- Packages by application count and monthly emails
- Free trial without a card
- Stops visibly when the quota is full; sending continues if the quota service is down
Your first email in five steps
1 · Register the application
Sign in to the panel with Passport and enter the application's name; a key and secret are generated, save the secret right away, it is shown once.
2 · Define the outgoing server
Enter your mail server's address, port, username, password and sender name; if a shared server already exists this step is skipped.
3 · Write the template
Write the subject and body with variables and give the template a name; the application will send that name and the values.
4 · Send the first request
Call the send endpoint from the application with the key and secret headers; the result returns at once and the message shows in the send history.
5 · Set up the list and the campaign
Pick recipients with filters and make the first bulk send; if it will recur, define a campaign rule with segment, template and interval.
Technology
- .NET 9 Web API
- PostgreSQL
- Background queue worker: bulk sends, campaigns, retries
- Standard SMTP outgoing server
- Sending from any language over plain HTTP
- Application key and secret headers
- Personal API keys
- Angular 20
- Turkish and English
- Docker containers, continuous delivery with Jenkins
- Passport single sign-on
- Subscription and quotas from the central subscription service
A sending centre is doing its job when the team answers 'did this email go out' without looking at server logs. That is why Herald keeps every send, successful or not, in a single history.
Frequently asked
What is Herald and what is it for?
Herald is a sending service that gathers the email sending of many applications into one centre. Applications drop requests at a single endpoint with their own keys; templates, recipient lists, bulk sends, recurring campaigns, outgoing server settings, send history and analytics are managed from one panel.
Which channels does it support?
Herald sends email. SMS, push notifications and messaging apps are not in scope; the product is designed today for the email channel only.
How do I connect my application to Herald?
You register the application in the panel and take its key and secret. The application calls the send endpoint with an HTTP request carrying both as headers; the language it is written in does not matter, and no extra library or server installation is needed. A Passport session is only for entering the panel, not for sending.
Can I use my own mail server?
Yes. The outgoing server is defined with standard mail server fields: address, port, username, password, sender address and name. You can define one shared server for all applications or give an application its own; the specific one takes priority. The sender address stays yours.
Does changing a template require a code change in the application?
No. The application sends only the template name and the variable values; the subject and body come from the template in Herald. When you change the template in the panel, the next sends go out in its new form. A variable whose value is not sent stays as it is, so missing data is noticed.
What happens if an email does not go out?
A single send is attempted immediately and its result returns with the request; if delivery fails later, the status shows as failed in the send history and it is requeued in one click. In bulk sends and campaigns a failed attempt is retried by itself at growing intervals, up to a limit.
Where does the recipient list come from?
Herald keeps its own recipient list and syncs it with the people using your applications; name, application and last sign-in are refreshed. The opt-out preference and bounce mark are preserved in sync, never reset. Recipients can also be added and edited by hand; in a bulk send, addresses can be pasted directly.
What happens when the monthly quota is used up?
New send requests are rejected until the package is upgraded; the send history and panel access are unaffected, and the state shows on the subscription screen. If the quota check is temporarily unreachable, sending does not stop; a critical email is never cut off because of the quota service.
Move your email sending into one centre
Tell us how many applications you have and where your email leaves from today; we will connect the first application together and set up templates and the outgoing server around your routine. You will be talking to the team that wrote the product, not a sales team.