Changelog

POST /v1/messages with "channel": "email" now accepts attachments, with written content or a template.

• Format: a list of objects {"filename": "invoice.pdf", "content": "<base64>"}, with an optional content_type (deduced from the file name otherwise).
• Limits: 10 files and 18 MB in total. Executable files (.exe, .js, .bat, .ps1…) are refused.
• Cost: unchanged.

The API now sends emails and verification codes by email, from your own verified sender address.

• Sending an email: POST /v1/messages with "channel": "email", up to 30 addresses per request. Write the content yourself (subject with message and/or html) or use one of your email templates with template_name.
• Variables: template_variables fills the {{name}}-style variables for the whole request. A missing variable is reported instead of leaving a blank.
• HTML and plain text: with both html and message, each becomes its own part of the email; with html only, the plain-text part is built for you; with message only, the email goes out as plain text.
• Reply address: reply_to takes up to 5 addresses, for example ["support@example.com"].
• Cost: an email written in the request is transactional, 1 credit per recipient. With a template, its category applies: 1 credit for transactional, 2 for marketing.
• Verification codes by email: POST /v1/verifications with "channels": ["email"], alone or with SMS and WhatsApp. Add email and email_sender_name; optionally email_template_name (it must contain {{code}}) and email_subject. Without a template, a plain email shows the code and its expiry. Always 1 credit.
• Delivery statuses: each recipient moves to delivered, read or failed, and your webhook receives delivered and failed, in the same format as SMS, with the email address in contact.

A campaign no longer requires a group. You can now pick contacts one by one from your address book and send straight to them, without creating a group first.

• Three sources, combinable: your groups, contacts picked from your address book, and numbers typed by hand. Use one of them, or all three in the same campaign.
• Recurrences too: the same applies when you schedule a repeating campaign.
• Counted once: a contact present in a group and also picked individually receives one message, and is billed once. The recipient count shown before sending is the deduplicated one.
• Discarded numbers are listed: a hand-typed number that is invalid or outside the allowed countries is reported back with its reason, instead of disappearing silently.
• Personalisation still works: picking a contact keeps their name attached to the message, so a message written with the recipient's name goes out personalised.

In the detail of a campaign, each recipient now shows the contact's name next to the number. You can tell at a glance who a message went to, without going back to your address book.

• Search by name: you can look a recipient up by name as well as by number, with no need for the full spelling. Searching by number works exactly as before.
• No name for some recipients: numbers typed by hand, and campaigns sent before this change, show the number alone.

A campaign can now repeat itself. You schedule it once and it goes out again on its own: every day, on the weekdays you choose, or on the days of the month you choose.

• Rhythm: daily, one or several weekdays, one or several days of the month, the last day of the month included. One hour of the day, accurate to the quarter hour.
• Every run is a real campaign: it lands in your history with its cost, its delivery statuses and its numbers. An integration that reads your campaigns or your messages sees them like any other, with nothing to change.
• Nothing is reserved up front: no credit is held when you create the recurrence. Each run checks your balance at the moment it is due.
• Not enough credit, or an empty audience: the run does not go out, you receive an email, and the recurrence stays flagged in the interface until a run succeeds.
• Stop and restart: a recurrence can be stopped and started again at any time. Missed runs are never caught up: it resumes at the next due date.
• Message and groups stay editable: without recreating the recurrence.

An automation module joins the dashboard. You describe a journey as a graph of blocks, and the platform runs it for every contact (or every record) that matches, with no action on your side.

• Four families of triggers: a contact created, updated, or added to and removed from a group; a date reached; a record read from your own API; a message delivered, a message failed, or an incoming reply.
• Blocks that chain: condition, wait (for a duration or until a date), send an SMS, WhatsApp or email message, save the contact, add to or remove from a group, set a variable, call a URL.
• Your API becomes a trigger: the pull trigger reads a public GET endpoint of yours that returns JSON, at the interval you choose (30 seconds minimum) or on a schedule. You map the fields of your records onto the variables of the journey, with phone normalisation, date parsing and default values along the way. Pagination is handled: page number, offset, cursor, or a next URL.
• Your systems get called: the call block lets a journey notify your application at the exact step you want, with the variables collected so far.
• Nothing changes for your integrations: the module is driven from the dashboard. Your SID and Secret Token are untouched, and no existing call behaves differently.

The dashboard now ships a Content Security Policy. The browser is given the exact list of origins the application is allowed to talk to, and refuses everything else: a script injected into the page can no longer load its own code or send your data to an outside address.

• Nothing changes for the API: these headers govern the browser only. Server-to-server calls, your SID and Secret Token, and your existing integrations are untouched.
• No embedding: the dashboard can no longer be displayed inside a frame on another site, which closes the door to clickjacking.
• Exfiltration blocked: connections and form submissions are limited to Nimba SMS and to the few services the interface actually needs.
• Camera, microphone and location denied: the interface never needs them, so the browser refuses them outright.
• Browser extensions: an extension that injects code into the page may print messages in the console. That is the policy working as intended, and does not affect your account.

A single account can now hold several organisations. Each one is a fully isolated environment, with its own data and its own API credentials, with no need to open a second account.

• Isolated data: contacts, groups, campaigns, sender names and message history belong to one organisation and are never visible from another.
• Its own API keys: every organisation you create gets its own SID and Secret Token. Point an integration at an organisation by using that organisation's credentials.
• Its own credits: each organisation carries its own SMS, WhatsApp and Email balance and buys its own credits. Nothing is shared between organisations, and a new one starts empty.
• Members: you can invite people into each organisation separately, with the role of your choice.
• Switching: the selector at the top of the sidebar lists the organisations you own and those you were invited to. Up to five organisations per account; contact support to raise the limit.
• Nothing changes for your current integrations: your existing SID and Secret Token keep working exactly as before, on the organisation your account started with. No header to add, no call to update.

A series of adjustments that come with organisations.

• Keys hidden by default: on the Developer page, the Secret Token and the Authorization header are masked; an eye reveals them. Copying still works without revealing anything. The Service ID stays visible: it is an identifier, not a secret.
• Authorization header explained: a note now states that it is your Service ID and Secret Token combined, base64 encoded, to be sent as is.
• One filter button: on the message, API send and OTP verification lists, the three filters are grouped behind a single Filter button that opens a window with status, sender and period. The button shows how many filters are active.
• Sidebar: the logo makes room for the name of the current organisation and the number of organisations held by the account.
• Personal details: name, company, email, phone and password are only editable from the organisation your account started with, since they belong to the account rather than to a workspace.

You can now sign in to your dashboard with your Apple ID, alongside the existing Google and LinkedIn options.

• Where: an Apple button sits at the top of the login window, next to Google and LinkedIn.
• Existing accounts: as with the other providers, signing in with Apple connects you to the Nimba SMS account that already carries the same email address. It does not create an account: to open one, go through the standard sign-up.
• Hide My Email: if you ask Apple to hide your address, it sends us a relay address (@privaterelay.appleid.com) that matches no account. Choose to share your real address, the one on your Nimba SMS account.
• Password unchanged: your password stays valid. Apple is an additional way in, not a replacement.

Any SMS already sent can be sent again in one click from your history, without retyping it.

• Where: a resend icon appears on each row of the Individual sends, API messages and OTP verifications histories.
• SMS only: WhatsApp is not eligible: the history keeps the rendered body, not the template and its variables, which Meta requires.
• Identical content: the dialog shows a read-only recap (sender, recipient, message). Nothing can be edited; to change something, use a regular send.
• A brand new message: a resend is not attached to the original one: it is billed as a new send and appears in Individual sends, whichever history it was triggered from. On an OTP verification, the message is resent as-is: no new code, no new expiry.

We've built full WhatsApp Business template management directly into the dashboard. You can create, edit, and submit templates to Meta for approval, then use them in campaigns.

• Template creation: two categories supported: Marketing and Utility, in French or English. Each template is composed of an optional header (plain text or media: image, video, document, or location), a body with dynamic variables ({{1}}, {{2}}…), an optional footer, and up to 3 buttons (phone number, website URL, or quick reply).
• Live preview: a real-time phone mockup updates as you type, showing exactly how the message will appear to recipients, including variable substitution.
• Meta submission: once saved as a draft, click Submit to send the template to Meta for review. The template is then locked in read-only mode until Meta approves or rejects it. Upon approval, it becomes available for campaigns.
• Editing approved templates: templates with Active or Rejected status can be edited and re-submitted to Meta. Category and language are immutable after the first submission. Upon re-submission, the template returns to Pending state while Meta re-reviews it.
• Authentication templates: automatically provisioned (one in French, one in English) when a WhatsApp sender is validated. They include the standard OTP body and an optional "Copy code" button, configurable from the dashboard.
• Webhook sync: template status (pending → active / rejected) is automatically updated in real time via Meta webhooks, with the rejection reason displayed when applicable.

Nimba SMS now provides an MCP (Model Context Protocol) server at https://mcp.nimbasms.com, enabling AI models (Claude, Cursor, etc.) to interact directly with your account: send SMS, manage contacts, and more. The ready-to-use configuration can be copied from the API Keys menu in your dashboard.

The maximum length of the message field has been increased from 5 to 7 SMS parts, allowing up to 1071 characters (7 × 153 characters for GSM-7bit multipart messages). This applies to the messages, campaigns, and notifications endpoints.

The developer documentation is now available in French and English. You can switch language from the top navigation. The OpenAPI schema, operation descriptions, parameters and response examples are translated according to the selected language. Schema responses are served with no-cache headers so that switching language reflects changes immediately.

Addition of the message_cost field in API responses for messages and verifications. This read-only field indicates the number of SMS consumed (message length in SMS count × number of recipients for messages, or 1 for verifications). It helps you track usage directly from the API response.