---
title: "Set Company Payer"
method: PUT
path: "/companies/{company_id}/payer"
tags: ["companies"]
---

# Set Company Payer

`PUT /companies/{company_id}/payer`

## Request

- Base URL: `https://app.zeno-works.ch` (the document declares no server; this is the origin it was published from)
- URL: `https://app.zeno-works.ch/companies/{company_id}/payer`
- Auth: none declared

Transfer who pays for this company (PRE-02) — current payer or admin only.

This is how a fiduciary pools their clients onto one account, and the remedy for
the payer FK's `ON DELETE RESTRICT`: a payer who must be deleted transfers their
companies first, deliberately, rather than having them silently unmetered.

It moves quota and subscription resolution and **nothing else** — no membership
is created or removed, no principal is widened, and no gate reads the result.
Deliberately not in `TIER1` and given no UI: it is a rare administrative act.

Runs under the **billing elevation** (`get_billing_scoped`), which also refuses a
company-scoped API key (ZET-176). The elevation is necessary rather than
convenient — a payer is often not a member of the company they pay for — and it
grants no authorization: `set_payer` does the payer-or-admin check itself.

**409** if the target user already pays for a company with this one's name. Company
names are unique per payer (`uq_company_payer_lower_name`), so a transfer moves this
company into a name-space that may already hold the name; the refusal names the
company in the way, because "rename one of the two, then transfer" is the remedy and
a bare constraint error would not say which two.

## Path parameters

- `company_id` string, required

## Headers

- `authorization` string, nullable

## Cookies

- `access_token` string, nullable

## Request body

- PayerIn: ``PUT /companies/{id}/payer`` body — who should pay for this company.
  - `payer_user_id` string, required

## Response `200`

Successful Response

- CompanyResponse: ``POST/PUT /companies/<id>`` → ``{"company": ...}`` (tenant fields only). Note: membership management (``user_company``) is NOT a company sub-resource in the api-contract — there are no member/role routes. Membership is edited via the users domain (the ``companies`` array or ``memberships`` list on ``POST/PUT /users/<id>``, A2); each membership carries a ``role`` (owner/accountant/member — doc/architecture.md §"Authentication & tenancy"; global ``User.is_admin`` bypasses role gates). See the companies router docstring + the agent report for this judgment call.
  - `company` CompanyOut, required: Serialized company tenant row + derived integration-presence flags.
    - `id` string, required
    - `company_name` string, required
    - `active` boolean, required
    - `is_demo` boolean
    - `ingest_lookback_months` 3 | 6 | 12, required
    - `language` 'de' | 'en' | 'fr' | 'it', required
    - `industry` string, nullable
    - `has_email` boolean
    - `has_epost` boolean
    - `has_bexio` boolean
    - `has_abacus` boolean
    - `has_storage` boolean
    - `has_accounting_settings` boolean

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/zeno-works/apis/zeno-api.md) · [All operations](https://skmtc.dev/zeno-works/apis/zeno-api/llms.txt) · [OpenAPI document](https://skmtc.dev/zeno-works/apis/zeno-api/revisions/1eb93dde146c?raw)