Changelog

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 — 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.