I'm building internal product alerts and want one notification API

You can absolutely design this as a single notification API.

A clean approach is to make one generic Notifications API that supports multiple event types, channels, priorities, and delivery rules. Then your product alerts become just one use case of that API.

Suggested shape

1. Core resource: notification

Use one endpoint to create a notification request:

POST /notifications

Example payload:

{
  "type": "product_alert",
  "title": "Price drop on Widget A",
  "message": "Widget A is now 20% off.",
  "recipients": [
    { "userId": "u_123" },
    { "role": "ops_on_call" }
  ],
  "channels": ["in_app", "email", "slack"],
  "priority": "high",
  "metadata": {
    "productId": "p_456",
    "sku": "WIDGET-A",
    "price": 19.99,
    "previousPrice": 24.99
  }
}

2. Delivery options

Support per-notification or policy-based channel selection:

• in_app
• email
• sms
• push
• slack
• webhook

3. Common fields

Good shared fields for internal alerts:

• type — event category
• title / message
• recipients
• channels
• priority
• dedupeKey — avoid duplicate alerts
• expiresAt — stop stale alerts
• metadata — arbitrary event context
• link — deep link to product/admin page

4. Useful API endpoints

Besides create:

• GET /notifications — list alerts
• GET /notifications/{id} — detail
• PATCH /notifications/{id} — update status/read state
• POST /notifications/{id}/ack — acknowledge
• POST /notifications/{id}/dismiss — dismiss

5. Internal product-alert specific behavior

For product alerts, you may want:

• thresholds: low stock, price change, outage, SLA breach
• routing rules: notify category owner, on-call, or slack channel
• deduping: one alert per product per condition
• escalation: if unacked after N minutes, send to another channel

Recommended architecture

If you want “one API” but flexible internals:

1. API gateway / notification service
2. Rules engine to map event → recipients/channels
3. Template service for message rendering
4. Delivery workers per channel
5. Audit log for sent/failed notifications

Minimal schema example

{
  "id": "n_001",
  "type": "product_alert",
  "status": "queued",
  "createdAt": "2026-10-14T12:00:00Z",
  "recipientCount": 3,
  "channels": ["in_app", "slack"],
  "dedupeKey": "product:p_456:price_drop",
  "metadata": {
    "productId": "p_456"
  }
}

Best practice

If this is for internal use, I’d strongly recommend:

• idempotency keys on create
• deduplication for repeated alerts
• templated content with variables
• tenant/team scoping
• delivery receipts and retries
• acknowledgement state

If you want, I can draft:

1. a full OpenAPI spec for one notification API, or
2. a database schema + service design for product alerts specifically.