Chimely
Api

Set preferences for a subscriber (admin)

PUT
/v1/subscribers/{subscriber_id}/preferences

Authorization

ApiKeyBearer
AuthorizationBearer <token>

Environment-scoped management API key.

In: header

Path Parameters

subscriber_id*string

Customer-provided subscriber id (e.g. usr_42).

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Partial upsert — listed (category, channel) pairs are written; unlisted pairs are untouched. Setting enabled=true deletes the explicit row (absence means enabled).

Response Body

application/json

application/json

application/json

curl -X PUT "https://example.com/v1/subscribers/string/preferences" \  -H "Content-Type: application/json" \  -d '{    "preferences": [      {        "category": "string",        "channel": "in_app",        "enabled": true      }    ]  }'
{
  "preferences": [
    {
      "category": "string",
      "channel": "in_app",
      "enabled": true
    }
  ]
}
{
  "error": {
    "code": "invalid_request",
    "message": "string"
  }
}
{
  "error": {
    "code": "invalid_request",
    "message": "string"
  }
}

Set own preferences PUT

Previous Page

SSE hint stream GET

`text/event-stream` of **hints, not transports**: the client refetches via REST (conditional, ETag) on every hint and on every (re)connect, so missed hints are harmless by construction. Auth via query parameters (browser `EventSource` cannot set headers). Server requirement (tested invariant, not a habit): `subscriber_hash` is scrubbed from access/proxy log lines for this endpoint — query-string credentials otherwise leak into logs. Events (`id:` on every event is an opaque resume token): * `hint` — something changed for this subscriber; refetch list/counts. Debounced server-side (at most one per subscriber per interval). Keep-alive is a comment frame (`: ping`) every 30 seconds, not an event — comment frames are deliberately invisible to EventSource listeners. Unknown future event types must be ignored by clients. Resume: browsers replay `Last-Event-ID` automatically on reconnect; the server answers by emitting an immediate `hint` if anything changed after that token (it does not replay individual missed events — the REST refetch is the recovery mechanism). On graceful shutdown the server sends a `retry:` directive with jitter before closing, so a deploy does not produce a reconnect stampede.