Leave time to undo workspace deletion
Requesting deletion closes the workspace to its members without immediately destroying its records. Wildo records a purge deadline so the operator has a recovery period before permanent removal.
Restoration is a separate operator action. It reactivates the organisation and clears the deletion marks while the organisation still exists.
Example — Recover a deletion requested by mistake
An administrator requests deletion and the workspace closes. Before it is purged, an authorised operator restores it and the members can work in it again.
For engineers
Mark the organisation through its deletion request
Both the tenant-administrator and platform-operator variants of Organization_Lifecycle_Operations.REQUEST_DELETION (request_deletion) require fresh authentication proof. The standard interface requests that proof before submitting the operation; permission to administer the workspace alone is not enough.
The internal operation key is request_deletion; the generated HTTP path uses request-deletion. Choose the variant that matches the caller:
| Request | Required authority |
|---|---|
PUT /organizations/{organizationId}/request-deletion | Organization administrator within that workspace |
PUT /organizations/{organizationId}/request-deletion/admin | Platform super-administrator; a cross-tenant caller also needs the applicable access grant |
For the tenant-administrator path, the request is:
curl -X PUT "$BACKEND_URL/organizations/$ORG_ID/request-deletion" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "x-reauth-token: $REAUTH_TOKEN" \
-H 'Content-Type: application/json' \
--data '{"reason":"The customer has asked to close this workspace"}'
REAUTH_TOKEN is the fresh proof returned by the application’s step-up authentication flow, for the same caller as ADMIN_TOKEN. It is not another name for the session token. The optional reason is limited to 500 characters. The operator variant uses the /admin suffix and also requires fresh proof; changing the URL does not grant platform authority or tenant reach.
The operation writes status: DELETED, deletionRequestedAt and purgeScheduledAt in the lifecycle transaction. It also reconciles assigned application user types granted by that organisation type and tied to membership through requiresOrgMembership.orgTypes. A type is retained while another qualifying active membership exists. Tokens are invalidated only when a type is actually revoked; closing the workspace separately removes its organisation-scoped authority.
Keep the deadline attached to this decision
The deadline is calculated from tenantTeardown.retentionWindowDays when the organisation is marked. Changing the configuration later does not rewrite deadlines already recorded. The warning belongs on this reversible mark, while someone can still ask for recovery. After marking, inspect all three stored values: DELETED, deletionRequestedAt and purgeScheduledAt. Repeating the mark on an already deleted organization is refused, so it cannot silently restart the recovery window.
Restore an existing marked organisation
restore requires platform authority and, for a non-member crossing, the appropriate access grant. It sets ACTIVE, clears both marks and re-grants organisation-derived user types. It does not restore a previous suspended or trial state.
An authorized platform operator restores the addressed organization with:
curl -X PUT "$BACKEND_URL/organizations/$ORG_ID/restore" \
-H "Authorization: Bearer $OPERATOR_TOKEN" \
-H 'Content-Type: application/json' \
--data '{"reason":"The closure request was withdrawn"}'
Arrange the target-organization access grant before using the cross-tenant path. After restoration, verify ACTIVE, cleared deletion timestamps and access through a qualifying membership. The reason is optional and limited to 500 characters.
The restoration gate tests that the row is marked, not whether its deadline has passed. Until purge actually removes the row, it can still be restored. Once the row is gone, addressing cannot find it. This makes the configured period a minimum recovery opportunity subject to the purge schedule, rather than a promise that removal happens at the exact deadline.