SK Notifications · Developers

Same rails as the whole suite.

Bearer keys, prefixed ULIDs, cursor pagination, idempotency on every mutation, signed webhooks. Learn it once for SK Notifications; it holds across all of Softknack.

01

How it fits together

Sends are idempotent and audited; channel fallback order is policy, not code. Submit a message with a channel strategy and the spine handles providers, breakers, retries and the audit trail.

fig · the shape of itsendwhatsappprovider Adegradedbreaker openreroute Ban outage is a reroute, not a lost messagedelivery is the contract
02

Your first message in three steps

Get a test key, make one authenticated call, and listen for the webhook. The same three moves work for every endpoint in the suite.

1

Get a test key

Test and live keys are separate environments. Build against sk_test_ without touching a real customer.

2

Create a message

One authenticated POST with an idempotency key. Same key + same body always returns the same result.

3

Receive the webhook

A signed message.created event hits your endpoint — verify the HMAC, act on it, return 200.

Terminal
curl -X POST https://api.softknack.com/notifications/v1/messages \
  -H "Authorization: Bearer sk_live_..." \
  -H "Idempotency-Key: 9f2c-4d1a-...-e7b3" \
  -H "Content-Type: application/json" \
  -d '{
    "contact_id": "ctc_01J9X...",
    "template": "appt_reminder",
    "channels": ["whatsapp", "sms"],
    "vars": { "time": "5:00 PM" }
  }'
03

Webhooks you can trust

Signed with HMAC-SHA256, delivered at-least-once, retried on a fixed schedule, and replayable from a dead-letter queue. You will never miss an event because a deploy was mid-flight.

EventWhen it fires
message.sentAccepted by the provider — id, channel, template.
message.deliveredConfirmed where the channel supports receipts.
message.failedFinal failure after fallbacks — with the why.
provider.circuit_openedA provider is misbehaving; traffic rerouted.
quota.thresholdApproaching a tenant limit.
message.repliedInbound reply on a two-way channel.
retry schedule
1s4s16s1m5m30m2hdead-letter
04

Guarantees, not vibes

The platform conventions every SK product obeys — learn them once, rely on them everywhere.

Idempotency, 24h

Every mutation takes an Idempotency-Key. Same key + body returns the original result; a conflicting body gets 409.

Prefixed ULIDs

Sortable, debuggable IDs like msg_01J9X... — you can read the type and the time right off the wire.

Cursor pagination

Stable cursors that never skip or repeat a row when data changes mid-list. No page-offset drift.

Row-level tenancy

Isolation enforced in the database. 404-over-403, so the existence of another tenant's record never leaks.

Signed webhooks

HMAC-SHA256 on every delivery, with the full retry schedule and dead-letter replay above.

Spec drift-checked

The OpenAPI spec is generated from the code's validators and checked in CI — the docs can't lie.

05

Bring your own agent

Send through one API and let the spine pick channels, fall back on failure, enforce quotas and write the audit. Every other SK product sends through this exact surface — and you can too, inheriting the same resilience instead of orchestrating providers yourself.

fig · MCP, scopedcatalogheadlessAPI · webhook · MCPservedyour agentsbuild on your catalog instead of being held by it
06

Just want to send one message?

A single POST with a template and a channel list sends it — with automatic fallback, a delivery receipt, and an audit record, no provider plumbing on your side.

The docs go deeper.

Auth, errors, pagination, every endpoint and schema — written once for the platform, shared by every product.

docs.softknack.com/notifications  See pricing →