`reactivate_subscriber`

Takes a bounced or complained subscriber back to active.

Call it: only when the address is known to work again and to want the mail.
Needs: an admin key with project_id (a project key is forbidden whatever its scopes), a reason, and a live list; suppressions stay (remove a hard_bounce or complaint one with remove_suppression).
Returns: the subscriber after the call, the same as POST /api/v1/projects/{project_id}/subscribers/{subscriber_id}/reactivate.

Arguments

object
reasonstringrequired

Why the address may get mail again; 1 to 256 characters, kept in the event subscriber.reactivated.

example the mailbox works again (ticket 4711)
subscriber_idstring · uuidrequired

The subscriber’s id.
project_idstring · uuid | null

The subscriber’s project; an admin key must pass it (only an admin key may reactivate).

No other arguments are accepted.

The result comes back as structuredContent, with the same JSON as a text block.

object · all fields required
attributesmap of string → string | number | boolean

The subscriber’s attributes: a map of string, number or boolean values.
confirmed_atstring · date-time | null

When the subscriber confirmed a double opt-in; null otherwise.
created_atstring · date-time
emailstring · email
idstring · uuid
list_idstring · uuid

The list the subscriber is on.
project_idstring · uuid

The subscriber’s project.
soft_bounce_streakinteger · uint32

Soft bounces in a row; reset by a delivery (P4+).

≥ 0
sourcestring

How the subscriber was added: api, import or confirm.
statusstring

pending, active, unsubscribed, bounced or complained.
unsubscribed_atstring · date-time | null

When the subscriber unsubscribed; null otherwise.
updated_atstring · date-time

The latest change: creation, an attribute merge.

A failed call answers isError: true with a code from the same table as the HTTP API, and detail. How tools report errors