# Courier vs Knock Source: https://wraps.dev/versus/courier-vs-knock Two notification layers that sit above your email, push and SMS providers rather than replacing them. The difference that decides it is not features — it is whether you are buying a platform with a floor or a meter with none. Neither of these delivers a message. Both sit above the providers that do, and sell you the things that get ugly when notifications outgrow a send call in a request handler: routing across channels, per-user preferences, digesting, batching, an in-app feed, and a place where the templates live that is not four files in two repositories. The decision between them turns less on capability, where they overlap heavily, than on pricing shape and on who you expect to be editing a workflow six months from now. ## At a glance |   | Courier | Knock | | --- | --- | --- | | What it is | Notification API and routing layer | Notification infrastructure across email, push, SMS, and in-app | | Published pricing | Pay-as-you-go at $0.005 per send, with no base fee. | $250/mo plus $5 per 1,000 notifications. | | Best for | Multi-channel notification routing without a platform fee, at low or spiky volume. | Cross-channel product notifications with user preferences and an in-app inbox. | | Watch out for | Also routes rather than delivers. At $5 per 1,000 it is fifty times raw SES for the routing alone. | It orchestrates rather than sends, so you still pay a sending provider underneath, on top of a $250 monthly floor. | Prices are each vendor's published list prices, verified August 2026. Check the vendor's own page before you sign anything. ## Where they actually differ ### The shape of the bill, and where it bites Courier Courier meters sends with no platform fee, so a system that notifies rarely costs almost nothing and the line item scales linearly and predictably with usage. That makes it easy to adopt for one feature without a budget conversation, and it means the cost of fanning a single event across four channels is four times the cost of one, which is a real incentive to be thoughtful about routing. Knock Knock charges a substantial monthly platform fee before the first notification, then meters on top. Below a certain volume you are paying for the platform rather than for delivery, which is a defensible thing to buy and an awkward thing to justify for a small product. Above it, the per-notification rate is what dominates and the floor stops being the thing anyone talks about. ### The in-app inbox Courier Courier offers an in-app component and treats it as one channel among several, consistent with its identity as a routing layer. It works, and the emphasis of the product is clearly on getting a message to the right place through the right provider rather than on the feed being the centrepiece of the experience. Knock Knock treats the in-app feed as a first-class product with its own API, real-time updates, seen and read state and prebuilt components. If what you are actually shopping for is the bell icon with the unread badge — the thing that is deceptively expensive to build well, because of read state, pagination and real-time sync — this is the more complete answer of the two. ### Preferences, and who is allowed to set them Courier Courier models preferences per recipient and per notification type and exposes a hosted preference page you can drop in. It covers the common requirement, which is letting a user turn a category off without you writing a settings screen, and it is deliberately not trying to be a consent management platform. Knock Knock's preference model is more structured, with categories, per-channel granularity and conditions, and it is one of the reasons teams with a compliance requirement end up there. The cost of that structure is that you have to model your notification taxonomy properly up front, which is more design work on day one and much less pain the first time legal asks what a user consented to. ### How a workflow gets authored and changed Courier Courier leans on a visual designer for templates and automation, which means a non-engineer can change copy and, within limits, behaviour. That is genuinely valuable and it introduces the problem every hosted editor has, which is that your notification logic now partly lives somewhere your version control cannot see. Knock Knock pairs a visual workflow builder with a command-line tool and environment promotion, so a workflow can be pulled down, committed, reviewed and promoted from development to production like any other artefact. For an engineering organisation that treats configuration drift as a real risk, this is the single strongest argument in Knock's favour. ### Who actually sends the message Courier Your providers do. Courier holds credentials for your email, push and SMS vendors and calls them, so the cost of delivery is on top of the routing fee and the deliverability is whatever your underlying vendor's is. The upside is that switching a provider is a configuration change rather than a migration. Knock Also your providers, with the same consequence: two invoices for one notification, and a platform fee underneath both. This is the fact that most surprises teams evaluating either product, because the pricing page of an orchestration layer naturally talks about orchestration and not about the sending bill that continues to arrive separately. ### Batching, digests and not being annoying Courier Courier supports throttling and digesting so that twenty events in a minute become one message, which is the feature that justifies this whole category more than any other. Hand-rolling a correct digest — with a window, a collapse key, and sensible behaviour when the window ends while the user is online — is a week of work that always gets deprioritised. Knock Knock's batching primitives are a first-class part of the workflow model rather than an option on a send, with explicit batch windows and keys you control per step. If digesting is the reason you are shopping, examine both carefully against your exact case, because the difference between these two is in the edge behaviour rather than in whether the feature exists. ### What you are not building if you buy either Courier A fan-out layer, a preference store, a template registry, a retry policy per channel and a deduplication key. Courier's pitch is that this is unglamorous plumbing every product rebuilds badly, and that pitch is correct. The question to ask is whether you need all of it or whether you need one piece of it. Knock The same list, plus the feed and the read state, plus environment promotion. Knock's larger surface is worth more when the notification system is a real part of your product rather than a supporting function. It is worth less when what you needed was to send three emails reliably and you have just acquired a platform to maintain. ### Seeing what a notification looked like afterwards Courier Courier keeps a log of each notification with the rendered content and the provider response, which is the thing you need when a customer says they never received anything and you have to determine whether the failure was routing, rendering or delivery. Retention follows the plan, and because sending happened at your own provider there is a second log elsewhere that has to agree with this one. Knock Knock exposes per-workflow and per-recipient message history with the state each step reached, which is a better fit for debugging a conditional workflow than a flat event log is. The same caveat applies about the provider's own record being the authority on delivery, and the same discipline applies: decide early which of the two systems is the one you actually trust. ### What happens if you leave Courier Your templates are in their designer and your routing logic is in their model, so the export is partial by nature. The mitigating factor is that the providers underneath were always yours, so leaving costs you the orchestration layer and not your sending reputation or your domain setup. Knock The command-line tooling means your workflows exist as files you already have, which makes the shape of your logic portable even though the runtime is not. That is a meaningfully better exit than a purely hosted configuration, and it is a reason to take the code-first path even if you like the visual builder. ## Pros and cons, side by side ### Courier Strengths - There is no floor to clear, so a feature that notifies a few hundred times a month can adopt the layer without anybody approving a subscription. - A non-engineer can change wording in the designer, which for a team whose copy is edited more often than its logic removes a recurring interruption. - The line item scales straight with usage, so a quiet quarter is cheap and nobody is defending a fixed cost against a fall in traffic. - Because the providers underneath were always yours, leaving costs you the routing layer and touches neither your domain setup nor your reputation. Trade-offs - Some of your notification behaviour now lives where version control cannot see it, which is only tolerable if nobody will ever ask what it was last quarter. - Fanning one event across four channels costs four times one, which is a real incentive to route thoughtfully and an odd thing to have to think about. - The feed is one channel among several rather than the centre of the product, so a team shopping specifically for the bell icon is buying the lesser of the two. - The preference model covers the common case and is deliberately not a consent platform, which matters the first time somebody in legal asks a precise question. ### Knock Strengths - A workflow can be pulled down, committed, reviewed and promoted between environments, so notification behaviour is governed the way everything else you ship is. - Batch windows and keys are explicit steps you control per workflow rather than an option attached to a send, which is what you want when the edges matter. - The feed is a product in its own right, with seen and read state and components, which is the piece teams most reliably underestimate before building it. - Because the workflows already exist as files on your machine, the shape of your logic survives a change of supplier even though the runtime does not. Trade-offs - A substantial monthly fee falls due before the first notification, which is hard to justify for a product that has not yet decided this layer is permanent. - The preference model asks you to design a notification taxonomy on day one, and there is no way to defer that decision and tidy it later. - It is a larger surface to learn and to maintain, which is a poor trade for a team whose actual requirement was three reliable emails. - The fee and the metering sit on top of a delivery bill that continues to arrive separately, so one notification is genuinely two costs. ## Pick in thirty seconds ### Choose Courier if - Volume is low or spiky and a monthly platform fee before the first notification is hard to justify to whoever signs it off. - You want to adopt a notification layer for one feature without committing the whole product to it. - A non-engineer changing notification copy in a visual editor is a benefit rather than a governance problem in your organisation. - Routing across providers with failover is the specific pain, and the in-app feed is not part of what you need. ### Choose Knock if - The in-app inbox with unread state is one of the things you are buying, not an extra you might use later. - Workflows need to live in version control and be promoted between environments like any other code. - Your preference requirements are granular enough that somebody will eventually ask you to prove what a user opted into. - Notification volume is high enough that the platform fee is a small fraction of the total and the per-message rate is what matters. ## What actually moves when you switch In roughly the order you would do it. The expensive parts of an email migration are never the send call. 1. Write down the exact digest behaviour you need at the boundary, because both products do digesting and the difference between them lives in the edges. What happens when the window closes while the person is looking at the screen? Does a late arrival extend the window or open a new one? What is the key that decides two events belong in the same digest, and what does the message say when the digest contains one item? Answer those four for your own case first, then evaluate against the answers rather than against a feature list. 2. Add the delivery bill to the orchestration bill before comparing anything, because neither pricing page will do it for you and the omission changes the ranking. An orchestration product naturally talks about orchestration; the messages still leave through a provider you pay separately, at that provider's rate, for every channel a workflow fans into. Build one number per notification — the layer plus every provider it touches — and then model it at the volume you expect in two years, which is where a fee and a meter cross over. 3. List the provider credentials you are about to hand across and decide what each one can do. A sending key that can despatch anything from your domain is a broader capability than the notification layer needs, and once it is stored at a third party the blast radius of a compromise there includes your outbound mail. Where the provider supports a scoped key, issue one. Where it does not, note the exposure somewhere a security reviewer will find it, and set a rotation date rather than trusting that somebody will think of it. 4. Define what failover means to you before treating it as a solved feature. Both layers retry and both can route to an alternative channel, and neither can tell the difference between a provider that returns an error and a provider that accepts a message and quietly discards it. The second failure is the one that actually hurts, and detecting it needs delivery telemetry you collect yourself and a threshold somebody watches. Buy the routing, keep the monitoring, and do not let the existence of a fallback path stand in for knowing whether mail is arriving. 5. Decide which of the two logs you trust before a customer makes you choose in a hurry. The layer records what it decided and what it handed over; the provider records what it accepted and what happened next. They will disagree, usually because one of them is recording an attempt and the other a result. Nominate the authoritative one per question — routing versus delivery — write that down beside the runbook, and make sure the identifiers in each are correlatable, because reconciling by timestamp and recipient at three in the morning is miserable. 6. Settle where the copy is allowed to change without a review, and be specific rather than principled about it. A hosted designer that a writer can edit is genuinely useful and genuinely means production behaviour can change with no record. The workable compromise is usually a boundary: wording is editable, routing and conditions are not. Whether your chosen product can express that boundary is a real question to ask during evaluation, and the answer is more interesting than whether it has a visual builder. 7. Adopt on one notification type rather than migrating everything, and decide in advance what would make you expand or stop. A single well-chosen case — the one with a digest requirement, or the one that already fans across two channels — exercises most of the layer and costs almost nothing to abandon. Set the criteria before you start, because a pilot without a stopping rule turns into a permanent second system by default, and a second system deciding independently what a user should be told is worse than either option on its own. 8. Check at adoption time, not at departure, how much of your logic would exist outside the supplier. A product whose workflows are files gives you an artefact you already have on disk, which means an exit costs you a runtime rather than a design. A product whose logic is configuration in a console gives you an export that is partial by nature. This is not an argument against the console — it is an argument for knowing which one you chose, and for keeping a written description of the behaviour if the tool will not keep one for you. ## Questions to ask before you sign Put these to a sales rep, or find the answer in the documentation before anyone quotes you a number. 1. When a digest window closes while the person is on the screen, what do we want to happen, and does this product do it? 2. What does one notification cost us once the provider's own charge is added to the layer's? 3. Which provider keys are we handing over, what can each of them do, and when do they rotate? 4. How would we find out that a provider accepted our message and then dropped it, given that no layer can tell us? 5. When the layer's log and the provider's log disagree, which one do we treat as the answer? 6. Can we let somebody edit the wording without letting them change the routing, and does the product support that line? 7. Which single notification are we piloting on, and what result would make us stop rather than expand? ## Common questions ### Do I need a notification layer at all? Not until three things are true at once: you send through more than one channel, users can turn categories off, and somebody has asked for digesting. With one channel and no preferences, a send call in your application is the correct architecture and a notification platform is overhead. The moment the second channel arrives, the fan-out logic, the preference checks and the per-channel retry policy start multiplying, and that is the point where buying beats building. ### Do these replace my email provider? No, and this is the most common misunderstanding about the category. Both orchestrate across providers you already have, holding your credentials and calling your vendor's API. You keep paying for sending, you keep owning your domain authentication, and deliverability remains a property of the provider underneath. What you are buying is everything that happens before the send call, not the send itself. ### How much of this could I build myself in a sprint? The naive version, easily: a table of preferences, a switch on channel, a template lookup. What takes longer than a sprint is the part that shows up later — idempotency so a retried job does not notify twice, digest windows that behave correctly at the boundary, per-channel backoff, read state that syncs across two open tabs, and a way to change copy without a deploy. Teams usually build the first version, ship it, and buy the second one. ### Can I use one of these only for the in-app feed? Yes, and it is a reasonable way in. Keep sending your email the way you already do, and use the notification layer only for the feed and the read state, which is the piece that is genuinely awkward to build. The risk is the seam: two systems now decide independently what a user should be told, and they will drift, so plan to consolidate rather than treating the split as permanent. ### What does either do when a downstream provider is failing? Both retry and both support routing to an alternative channel or provider, which is one of the better arguments for the category. Read the specifics carefully, because the useful behaviour is not retrying — everything retries — it is whether a provider returning success while silently dropping mail counts as failure. Neither product can know that, which means your fallback strategy still depends on delivery telemetry you are collecting yourself. ### How do I choose a digest window without annoying people? Start from what the reader is trying to avoid, not from a duration. Somebody who is mentioned nine times in a busy thread wants one message; somebody who is mentioned once wants it now. That argues for a short window with a collapse key on the conversation rather than a long window on the person, because the long window delays the single important notification in order to solve a problem that only exists in bursts. The second decision is what happens at the boundary, and it is the one that gets skipped: if a tenth mention arrives one second after the window closes, does it extend the digest or start a new one, and if the answer is start a new one, has the reader now received two messages about the same thread? Pick the behaviour deliberately, write the case into a test, and check the product can actually express it — because both of these can digest, and where they differ is exactly here. ### Is it safe to give a third party my sending provider's key? It is normal and it is not free, and the useful posture is to treat it as an exposure you have priced rather than a risk you have dismissed. A key that can send from your domain, in the hands of anyone who compromises the layer, can send anything from your domain — phishing that authenticates correctly, because it genuinely is you. The mitigations are ordinary. Issue a scoped key if your provider supports scoping, so the credential can send and nothing else. Give the layer its own key rather than sharing the one your application uses, so that revoking it does not take your product down with it. Set a rotation date at the moment you create it, because nobody ever rotates a credential they did not schedule. And note the arrangement where a security reviewer will find it, since the question of who holds keys to your sending identity is one that gets asked eventually and is much better answered from a list than from memory. ### Should I pilot one notification or migrate all of them? One, almost always, and with a stopping rule written down before you begin. Choose the case that exercises the most of the layer for the least risk — usually the one that already fans across two channels or already needs a digest — and leave everything else where it is. That gives you a real answer about the product within a fortnight, at a cost you can abandon. The discipline that is easy to skip is defining in advance what result would make you expand and what result would make you stop, because without it a pilot does not end; it simply becomes a second system, and two systems deciding independently what a user should be told will drift and will produce the duplicate nobody can explain. Put a date on the review, name who makes the call, and be prepared for the honest third outcome, which is that the layer is good and your requirement was smaller than the category. ### Which of these is easier to leave? The one whose workflows are already files on your machine, and the margin is larger than it sounds. Notification logic is not the hard part to rebuild in the abstract — it is a set of conditions, channels and templates — but it is very hard to rebuild accurately from memory eighteen months after somebody assembled it in a browser. A product with command-line tooling and environment promotion leaves you holding a description of the behaviour regardless of whether you keep paying, which turns an exit into a reimplementation against a specification instead of an archaeology exercise against a screen. The consolation on the other side is that neither product holds the thing that is genuinely expensive to move: the providers underneath were always yours, so your domain authentication, your sending reputation and your delivery history stay exactly where they are. Leaving an orchestration layer costs you orchestration. That is a much better position than leaving a platform that also sends.