---
title: "Recover Company"
method: POST
path: "/recover/companies/{company_id}"
tags: ["Company"]
---

# Recover Company

`POST /recover/companies/{company_id}`

Recover tombstoned company and all associated workspaces

## Path parameters

- `company_id` string, required

## Response `200`

The company that was recovered

- Company — A billing company
  - `id` string — The ID of the Company
  - `name` string — The Company name
  - `created_time` integer — Time at which the account was created
  - `created_by_id` string — The ID of the user who created this account
  - `last_updated_time` integer — Time at which the account was last updated
  - `last_updated_by_id` string — The ID of the user who last updated this account
  - `sso_connections` CompanySSOConnection[] — Array of sso connections
    - `connection_id` string — ID of SSO connection entity
  - `session_timeout` 'default' | 'hours_04' | 'hours_08' | 'hours_10' | 'hours_12' | 'hours_24' | 'hours_72' — The desired session timeout
  - `link_infrastructure_key` string — Key of the dedicated Link (mablnet) infrastructure cluster this company's tunnels are pinned to (e.g. `acme` -> `acme-wss.link.mabl.com`). Absent for the multi-tenant shared cluster (key `mabl`). Operator-managed via PUT/DELETE /companies/{id}/linkInfrastructureKey only — never via the generic company update.
  - `link_access_config` LinkAccessConfig — Consent settings governing who may reach a Link (mablnet) tunnel owned by this workspace or company. Deliberately separate from support_access_config: not all of this has anything to do with support, and reaching a customer's network is a distinct decision from seeing their workspace. This is the set an owner of either kind carries. A workspace additionally carries enable_personal_tunnels — see WorkspaceLinkAccessConfig, which extends this. That flag is meaningless for a company: a personal tunnel belongs to a user, and both halves of the decision it governs are asked of a workspace. Everything here is opt-in. An absent config, and an absent setting within a present config, both admit nobody; only new trial workspaces are created with anything enabled. None of this affects api-key access to a tunnel — an `execution` key reaching a tunnel for a cloud test run is unaffected throughout.
    - `created_time` integer — created time, epoch millis
    - `created_by_id` string — created by user id
    - `last_updated_time` integer — last updated time, epoch millis
    - `last_updated_by_id` string — last update by user id
    - `enable_link_access_by_support` boolean — When true, a mabl support admin may reach the tunnel's published services, such as the SOCKS proxy and reachability probes. When false they may still reach the tunnel's control plane — draining a host, inspecting carriers — which is never gated, but no traffic-carrying service.
    - `member_access_roles` LinkAccessRoleEnum[] — Which member roles may reach the tunnel's published services with their own credentials — the tunnel's audience. A caller is admitted when they hold at least one role named here, so holding a role is necessary and never sufficient: the owner has to have named it. An empty array admits nobody, which is where every owner starts, and leaves only api keys — cloud execution is unaffected. Absent and empty both admit nobody; the difference is about the PATCH, not about access. A PATCH omitting this field leaves the audience as it is, and one sending an empty array clears it.

## Other responses

- `400` — Invalid or missing parameter
- `401` — User not authenticated
- `403` — User not authorized
- `404` — No company to recover
- `default` — Unexpected error

---

[API](https://skmtc.net/mabl/apis/mabl-api.md) · [All operations](https://skmtc.net/mabl/apis/mabl-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/mabl/mabl-api/revisions/d0fc0114da66/schema)