---
title: "Replace your alert destinations"
method: PUT
path: "/v1/me/alert-destinations"
tags: ["Alert Destinations"]
---

# Replace your alert destinations

`PUT /v1/me/alert-destinations`

## Request

- Base URL: `https://api.subscriby.net`
- URL: `https://api.subscriby.net/v1/me/alert-destinations`
- Auth: HTTP bearer

Takes the complete list you want to keep; anything not in it is removed. Each entry names a `kind`, a `target` and optional `classes`:

```bash
curl -X PUT https://api.subscriby.net/v1/me/alert-destinations \
  -H "Authorization: Bearer $SUBSCRIBY_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "destinations": [
      { "kind": "connector_identity", "target": "0c2d8a7e-4b1f-4d3e-9a6b-2f5e8c1d7a90", "classes": ["sales", "support", "passes"] },
      { "kind": "email", "target": "ada@example.com", "classes": null }
    ]
  }'
```

The response is the resulting list. `PUT` is a replacement, not a patch: send an empty `destinations` list to remove every row and return to the default. `is_primary` in the payload is ignored; the service derives it from your linked identities.

When a creator alert is sent, every connected account routed to its class receives a message through that connector, and email is used when an email destination routes the class, when no connected account does, or when the class is critical. The same routing decides whether the bot messages you at all about a sale, a waiting member or a pass window: a class you route away from an account is never sent there. A newly linked primary account receives a destination for every class automatically, so linking keeps working as it did; unlinking the account removes its destination.

## Headers

- `Idempotency-Key` string, uuid, required

## Request body

- UpdateAlertDestinationsRequest: The complete set of alert destinations to keep. Anything not listed is removed; an empty list returns you to the default routing.
  - `destinations` object[], required: Every destination you want, at most 20. The key must be present; an empty list removes every row and restores the default.
    - `kind` 'connector_identity' | 'email' | 'push_device', required: What kind of place a creator's alert can be sent to. A connector identity is reached through that connector's messenger, an email through mail, and a push device through the mobile apps once they exist; the kind decides which channel the router picks, and adding a kind is a case here and a row per creator, never a schema change.
    - `target` string, required: The connected account's id or the email address. It must be one of your own linked accounts or your own address; anything else is refused with `404 RESOURCE_NOT_FOUND` and nothing is written.
    - `classes` AlertClass[], nullable: The alert classes to route here, any of `sales`, `support`, `recovery`, `billing`, `security`, `passes`, `onboarding`. Send `null` for every class or `[]` for none. `is_primary` is not accepted; the service derives it.

## Response `200`

Array of `AlertDestinationResource`

- object
  - `data` AlertDestinationResource[], required: The items.
    - `id` string, required: The destination's id.
    - `kind` string, required: `connector_identity` for a connected account, `email` for an address. `push_device` is reserved for the creator apps.
    - `target` string, required: The connected account's id (the same value `GET /v1/me/identities` returns behind a linked identity) for `connector_identity`, or the email address for `email`.
    - `classes` string[], nullable, required: The alert classes routed here: any of `sales`, `support`, `recovery`, `billing`, `security`, `passes`, `onboarding`. `null` means every class; `[]` keeps the destination but sends it nothing.
    - `is_primary` boolean, required: Whether this is the destination of your primary connected account. Derived from your linked identities, never set through the API.
    - `verified_at` string, nullable, required: When the destination was confirmed reachable, ISO 8601; null while unverified.

## Other responses

- `400`: `IDEMPOTENCY_KEY_MISSING`: every write needs an `Idempotency-Key` header. Send a fresh UUID per distinct operation.
- `401`: `AUTHENTICATION_REQUIRED`: the request carries no bearer token, or one that is revoked, malformed, or minted for another environment (an `sbt_test_` token on production).
- `403`: `TOKEN_MISSING_ABILITY`: the token is valid but does not carry the ability this endpoint requires; `error.context.required_ability` names the one to grant. An endpoint that also checks who owns a row or which tier the account is on answers `FORBIDDEN`, `TEAM_TIER_REQUIRED` or `CONNECTOR_TIER_REQUIRED` with the same status, and says so in its own description.
- `404`: `RESOURCE_NOT_FOUND`: when a `target` is not one of your own linked accounts or your own address; nothing is written.
- `409`: `IDEMPOTENCY_KEY_REUSED`: the key was already used in the last 24 hours with a different request body.
- `422`: `VALIDATION_FAILED`: the payload broke a rule, and `error.fields` maps each offending key to its messages. A refusal from the domain, such as a plan that cannot go on sale or a member who cannot be removed, uses the same code with `error.message` saying why and no `fields`. On this endpoint: `VALIDATION_FAILED`: when `destinations` is missing, holds more than 20 entries, or an entry has an unknown `kind` or class.
- `425`: `IDEMPOTENCY_REPLAY_IN_PROGRESS`: the first request with this key is still running; retry in a few seconds and the original response is replayed.
- `429`: `RATE_LIMITED`: the token has spent its 300 requests a minute or 10,000 an hour; `Retry-After` says when the next one is accepted.

---

[API](https://skmtc.dev/memberpass/apis/subscriby-rest-api.md) · [All operations](https://skmtc.dev/memberpass/apis/subscriby-rest-api/llms.txt) · [OpenAPI document](https://skmtc.dev/memberpass/apis/subscriby-rest-api/revisions/59c4df91d764?raw)