Services
Every message Cnter sends, who it goes to, and why your site should not send its own.
Cnter emails on its own, at the moments a module defines. Confirmations, status changes, reminders and notifications to your customer all come from here, using templates they edit themselves. The most useful thing to know as an integrator is which messages already exist, so you do not send them twice.
What gets sent
Templates are per module and per organization. Turning a module on makes its templates available; your customer edits the wording, the sender name and the recipients.
| Module | Templates |
|---|---|
| Bookings | Booking confirmation, booking reminder, booking cancellation. |
| Online Ordering | Order confirmation to the buyer, and a copy to the organization. |
| Restaurant Ordering | Order accepted, order ready, out for delivery, order cancelled. All to the buyer. |
| Reservations | Request, approval and cancellation, each in a version for the guest and a version for the organization. |
| Contact Form | A notification to the organization and a confirmation to the person who wrote in. |
A notification uses the template chosen for it only when that template is one of the organization's own; otherwise, as when none was chosen, it uses the organization's default for that type. Pointing a notification setting at any other template is refused with 404 TEMPLATE_NOT_FOUND, the same answer as for one that does not exist.
How it is sent
By default, mail goes out through Cnter with no setup. An organization that wants messages from their own domain configures their own SMTP server under Settings then Organization then Email, with a test send to prove it works before anything real depends on it.
This matters to you only in one way: deliverability is your customer's domain problem, not a bug in your integration. If confirmations are landing in spam, the answer is SPF and DKIM on their domain, not a change to your checkout.
Variables
Templates are written with placeholders, filled in at send time from three places:
| Source | Holds |
|---|---|
| System variables | What the platform knows: order number, total, guest name, date, status. |
| Organization variables | What your customer defined once: address, phone number, opening hours, a signature line. |
| Request variables | What you passed with a single submission, in email_variables. Overrides the organization value for that message only. |
The last one is the only lever you have from a website, and it exists for the case where your form knows something the dashboard cannot: which branch the enquiry is about, which campaign it came from, which language to answer in.
{
"name": "Noor van Elderen",
"email": "noor@example.com",
"message": "Do you cater for groups of twelve?",
"email_variables": {
"branch": "Kade 9",
"reply_language": "nl"
}
}When email fails
A failed send never fails the operation. A booking that could not be confirmed by email is still a booking; a contact submission whose notification bounced is still stored and visible in the dashboard. The failure is logged, the record stands.
For you that means a 201 is not a promise that an email arrived. If your interface says "check your inbox", say it as an expectation rather than a fact, and give people the information on screen as well.
Invitations
Team invitations are email too, and worth knowing about because it is the first message anyone in a new organization receives. An invite is one link that resolves to the right step, whether the recipient already has an account or is starting from nothing. There is nothing to integrate: it is how your customer gets their staff into the dashboard.