Deactivate an organization
This endpoint is only available to organization owners.
POST https://your-org.collaborychat.com/api/v1/realm/deactivate
Deactivate an organization on the
Zulip server. Deactivating an organization immediately logs out all of
its users and prevents them from logging in again.
A deactivated organization can be reactivated via a management
command,
unless its data has been permanently deleted (see the
deletion_delay_days parameter
below).
This endpoint is primarily useful for Zulip servers that host
multiple organizations.
Usage examples
The -u line implements HTTP Basic authentication.
See the Authorization header documentation for how
to get those credentials for Zulip users and bots.
curl -sSX POST https://your-org.collaborychat.com/api/v1/realm/deactivate \
-u EMAIL_ADDRESS:API_KEY \
--data-urlencode deletion_delay_days=30
Parameters
deletion_delay_days integer | null optional
Example: 30
The number of days to wait before permanently deleting all
of the deactivated organization's data (users, channels,
messages, etc.).
A value of 0 will delete the organization's data
immediately, which means that the organization cannot be
reactivated. A null value indicates that the organization's
data will not be deleted, but rather retained indefinitely.
Valid values for this parameter are limited to the range
permitted by the server, indicated by the
server_min_deactivated_realm_deletion_days and
server_max_deactivated_realm_deletion_days fields in the
POST /register response. A value of
null is only permitted when
server_max_deactivated_realm_deletion_days is null. A
value of 0 is only permitted when
server_min_deactivated_realm_deletion_days is null.
These limits do not apply to
Zulip Cloud demo organizations,
for which this parameter is instead required: it must be 0
when the organization owner has not configured an email
address, and otherwise must not exceed the number of days
remaining before the demo organization's scheduled deletion.
Changes: New in Zulip 10.0 (feature level 332).
Response
Example response(s)
Changes: As of Zulip 7.0 (feature level 167), if any
parameters sent in the request are not supported by this
endpoint, a successful JSON response will include an
ignored_parameters_unsupported array.
A typical successful JSON response may look like:
{
"msg": "",
"result": "success"
}
An example JSON response for when the current user is
not an organization owner:
{
"code": "UNAUTHORIZED_PRINCIPAL",
"msg": "Must be an organization owner",
"result": "error"
}
An example JSON response for when deletion_delay_days
is below the minimum permitted by the server:
{
"code": "BAD_REQUEST",
"msg": "Data deletion time must be at least 14 days in the future.",
"result": "error"
}
An example JSON response for when deletion_delay_days
exceeds the maximum permitted by the server:
{
"code": "BAD_REQUEST",
"msg": "Data deletion time must be at most 30 days in the future.",
"result": "error"
}
An example JSON response for when an invalid
deletion_delay_days is given for a
Zulip Cloud demo organization:
{
"code": "BAD_REQUEST",
"msg": "Invalid data deletion time for demo organization.",
"result": "error"
}
