contacts

Set Preference

put/v1/contacts/{contact_id}/preferences

Request

  • Base URL: https://api.elaan.io (the document declares no server; this is the origin it was published from)
  • URL: https://api.elaan.io/v1/contacts/{contact_id}/preferences
  • Auth: none declared

Path parameters

contact_idstring required

Headers

authorizationstring nullable

Request body

notification_type_keystring required
channel'email' | 'inbox' | 'push' | 'web_push' required

A delivery channel a notification can be sent over.

This is an enum (not a bare string) so adding SMS / WHATSAPP later is a one-line change and every per-channel mapping (notification-type defaults, contact preferences) extends automatically. Crucially, a newly-added channel is opted out by default everywhere: NotificationType.default_for returns False for a channel absent from channel_defaults, and a contact has no preference until they set one — so an existing install gains a channel that delivers to nobody until a tenant explicitly enables it. That's why adding a member needs no data migration.

Subclassing str makes members compare/serialize as their value ("email"), which keeps JSON and dict keys clean.

enabledboolean required

Example request

{
  "notification_type_key": "order_shipped"
}

Response

Successful Response

idstring required
external_idstring nullable required
languagestring nullable required

The contact's preferred language tag (e.g. "es"), or null for the language-less default. Set at create or via PUT /v1/contacts/{id}/language — deliberately NOT part of the whole-resource PUT, so a partial-shaped update can't silently clear it.

emailsstring[] required
phonesstring[] required
attributesobject required

Example response

{
  "push_subscriptions": [
    {
      "value": "fcm-token-abc",
      "auth": "kQm...==",
      "p256dh": "BN1...=="
    }
  ],
  "preferences": [
    {
      "notification_type_key": "order_shipped"
    }
  ]
}

Changes

No recorded changes to this operation across all 1 revision of this API.