How Notis Delivers an AI Assistant Inside WhatsApp With Twilio

Nobody wants another app. They want the thing they already have open to become more useful.

That belief is most of Notis. You send a voice note to a WhatsApp contact and your notes get written, your tasks get filed, your research comes back. No install, no new icon, no "where did I put that tool."

Twilio is what makes WhatsApp a real channel for us rather than a demo.

WhatsApp is not a chat widget

From the outside, "we're on WhatsApp" sounds like a small integration. It isn't, and the reasons are all things you discover after you've promised it.

WhatsApp is a permissioned network. You cannot simply message a user because you have their number. There are rules about who can start a conversation and when, template approval for anything outside an open session window, and per-market restrictions that change. Media has its own constraints. Delivery is asynchronous and can fail for reasons on the user's side that you learn about minutes later, if at all.

Twilio's job is to be the layer that understands all of that so our backend can think in terms of "reply to this person with this content."

Our sending code covers the full surface: ordinary session messages, approved templates for outbound that falls outside a session, media in both directions, and delivery status callbacks. Inbound webhooks are signature-validated before we act on them, because an endpoint that accepts unauthenticated messages claiming to be from your users is a very bad endpoint to have.

The unglamorous half: delivery failure

Here's the thing I didn't appreciate before building a messaging-native product.

In a web app, if something fails, the user is looking at it. They see a spinner, an error, a retry button. The failure and the person are in the same place.

In a messaging product, the user sent a voice note and walked away. If the reply never lands, their experience is not "an error occurred." It's "the assistant ignored me." That's much worse, because it reads as unreliability rather than a bug.

So delivery callbacks aren't telemetry for us, they're product logic. We track delivery references for outbound messages, record failures per channel, and distinguish transient problems from terminal ones. When a channel has permanently stopped accepting delivery — a number changed, a session expired, a restriction kicked in — the user gets told through a different route, because the broken channel obviously can't tell them.

An assistant that fails loudly is more trustworthy than one that fails politely.

Why one provider across several channels

Twilio also backs the SMS and voice paths in our codebase. I'll be careful here: code existing is not the same as a feature being generally available, and I'm not going to claim volumes I haven't audited. WhatsApp is the mature story.

But the reason those paths live with the same provider is architectural. Every channel Notis supports has to answer the same questions: how does a message arrive, how is it authenticated, how do we attach it to the right user and thread, how do we send back text and media, and how do we learn that delivery failed.

When channels share a provider, they share those answers. Adding a capability means teaching one integration a new trick rather than starting a new one from scratch. When they don't — and we do run other channels on other providers — every one of those questions gets a fresh, slightly different answer, and the differences are where the bugs live.

There's a real trade-off in concentration, which is why Twilio appears by name in our Help Centre's platform providers overview alongside their security posture. If a provider can see your users' messages, users should be able to see who that provider is.

What this actually feels like to use

The test I care about: can someone use Notis without ever learning that it's software?

You're walking to a meeting. You send a voice note: "Log that call with Marie, she wants pricing by Friday, remind me Thursday morning." The transcript happens, the notes get written where your notes live, the task gets created, the reminder gets scheduled, and a short confirmation comes back — in the same thread, next to the message you sent.

No app switch. No dashboard. The interface is the one you were already in.

That only works if the channel is boringly reliable. Every millisecond of latency, every dropped media file, every silent failure breaks the illusion that you're talking to something competent. Which is why most of the work here is not clever — it's making sure the plumbing never asks the user to think about plumbing.

If you're building a messaging-native product

Things I'd want to know earlier:

1. Read the platform rules before you scope the feature. Session windows and template approval are not implementation details; they shape what your product can do.
2. Validate inbound webhook signatures on day one. Retrofitting that is a security review you don't want.
3. Treat delivery callbacks as product logic, not analytics. Your user is not looking at a screen.
4. Have an out-of-band route for telling someone a channel is broken. The broken channel can't do it.
5. Design threading before you support your second channel. Identity across channels is harder than any single channel.

Notis is founder-led, Swiss-operated, and still expanding from voice-to-Notion capture into broader connected-tool workflows. The constant is that people reach us where they already are.

For a very large number of them, that's WhatsApp — and Twilio is why it works.