Knock API
Knock is a notification infrastructure platform focused on notification workflows and in-app notification feeds. Unlike basic transactional email APIs, Knock provides a workflow engine where you visually design multi-step notification sequences: wait steps, batch/digest steps, branch conditions, and channel delivery across email, SMS, push, Slack, and in-app feeds. Knock's in-app feed is a first-class primitive — a pre-built, real-time notification feed component (React, Angular, iOS, Android SDKs) that renders a bell icon / notification drawer, eliminating the need to build this common UI pattern. The API handles user identity, preferences, workflow triggering, and feed state management (read/unread/archived).
Score Breakdown
⚙ Agent Friendliness
🔒 Security
HMAC-signed user tokens for in-app feed are a strong security model that prevents user impersonation — this is the correct pattern and Knock enforces it in production mode. Secret/public key separation is clean. No token scoping granularity beyond the secret/public split — the secret key has full account access. Signing key rotation available in dashboard. Webhook payload verification via HMAC signature is documented and recommended.
⚡ Reliability
Best When
You need an in-app notification feed plus multi-channel notification delivery with workflow logic (batching, delays, branching) and don't want to build the notification infrastructure layer from scratch.
Avoid When
You only need simple transactional email, you need marketing campaign tooling, or you need to self-host your notification infrastructure.
Use Cases
- • Building in-app notification feeds (bell icon with unread count and notification list) without building the feed storage and real-time delivery layer
- • Implementing digest/batch notifications — collecting individual events and sending a single summary email after a quiet period using Knock's batch step
- • Designing multi-channel notification workflows visually: trigger → wait 10 min → if unread in-app, send email → else stop
- • Managing user notification preferences per channel and per notification type, with a hosted preferences UI or API-driven preference management
- • Triggering notifications from event streams or webhooks and routing them through complex conditional delivery logic without custom code
Not For
- • Marketing campaigns, newsletters, or audience segmentation — Knock is transactional and workflow-driven, not a marketing automation tool
- • Simple transactional email sending without workflow logic — dedicated ESPs (Postmark, Sendgrid) are cheaper and simpler for pure email
- • Teams that need to own notification storage and infrastructure entirely — Knock is a managed service; self-hosting is not available
- • Real-time chat or two-way messaging — Knock's in-app feed is a notification feed, not a chat system
Interface
Authentication
Secret API key for server-side REST API calls (Authorization: Bearer sk_...). Public API key for client-side SDK initialization (safe to expose). In-app feed requires a per-user signed user token (HMAC-SHA256 of user ID using a signing key) for secure user identification — without token signing, any user ID can be impersonated. Test and production environments have separate key pairs. No fine-grained token scoping beyond the secret/public split.
Pricing
Pricing is per notification sent across all channels. In-app feed messages count toward the notification limit. Free tier is generous for development and small production use. Annual plans available with discounts.
Agent Metadata
Known Gotchas
- ⚠ Workflow triggers are asynchronous — POST /v1/workflows/{key}/trigger returns HTTP 200 with a workflow_run_id immediately, but the workflow executes in the background; agents must use the workflow run API or webhooks to track execution status.
- ⚠ In-app feed requires HMAC-signed user tokens for secure operation — agents building client-facing features must generate signed tokens server-side per user session; using unsigned tokens (allowed in development mode) is insecure in production.
- ⚠ Batch/digest steps use time-window accumulation — triggering a workflow multiple times within a batch window accumulates notifications into a single digest; agents that need immediate delivery must configure batch window to 0 or use non-batched workflows.
- ⚠ Recipient users must be identified via PUT /v1/users/{id} before or alongside workflow triggers — sending a notification to an unidentified user ID creates a 'pending' user but may miss profile data needed for personalization in templates.
- ⚠ Workflow keys are defined in the Knock dashboard UI and referenced by string key in API calls — agents must maintain a mapping of workflow key strings that are managed outside of code, creating a coordination dependency between dashboard config and agent code.
- ⚠ Cancellation keys (workflow trigger cancellation) cancel ALL pending steps for a given cancellation key — agents using the same key for multiple triggers will cancel unintended workflows if they share a key accidentally.
- ⚠ Channel provider configuration (Sendgrid, Twilio, etc.) is managed in the Knock dashboard — agents triggering notifications will silently fail to deliver if the upstream provider is not configured or has invalid credentials in Knock's channel settings.
Alternatives
Full Evaluation Report
Comprehensive deep-dive: security analysis, reliability audit, agent experience review, cost modeling, competitive positioning, and improvement roadmap for Knock API.
AI-powered analysis · PDF + markdown · Delivered within 30 minutes
Package Brief
Quick verdict, integration guide, cost projections, gotchas with workarounds, and alternatives comparison.
Delivered within 10 minutes
Score Monitoring
Get alerted when this package's AF, security, or reliability scores change significantly. Stay ahead of regressions.
Continuous monitoring
Scores are editorial opinions as of 2026-03-07.