---
title: "Lookup Company Uid"
method: GET
path: "/companies/{company_id}/accounting-settings/uid-lookup"
tags: ["accounting-settings"]
---

# Lookup Company Uid

`GET /companies/{company_id}/accounting-settings/uid-lookup`

## 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}/accounting-settings/uid-lookup`
- Auth: none declared

Ask the Swiss commercial register who ``uid`` belongs to (accountant).

Advisory, read-only and **stateless** — it writes nothing, and its answer never gates
the PUT above. The UID column is free text on purpose (it also holds foreign VAT
numbers, ZET-364), so the register's job here is to let the person typing it compare
a name, not to rule on the value.

**Every register outcome is a 200** carrying ``status`` — including "unreachable".
A federal endpoint being down is not the caller's error, and mapping it to a 5xx
would put an English sentence in a four-language dialog for a condition the user can
neither cause nor fix. See :mod:`invoiage_core.zefix`.

Behind ``CompanyAccountant``, the same guard as the PUT that writes the field: only
an accountant can edit the UID, so only an accountant can drive traffic at the
register from our address.

## Path parameters

- `company_id` string, required

## Query parameters

- `uid` string, required

## Headers

- `authorization` string, nullable

## Cookies

- `access_token` string, nullable

## Response `200`

Successful Response

- RegisterLookup: What the register says about one UID — also the endpoint's wire shape. One type rather than a client dataclass plus a response model: the endpoint is a pass-through, so a second shape would only be the first one retyped. ``status``: * ``found`` — the register knows it; the remaining fields describe the entry. * ``not_found`` — the query ran and matched nothing. * ``invalid`` — the input does not read as a Swiss UID. **Not an error**: the column legitimately holds foreign VAT numbers, so the register simply has no opinion, and the UI renders nothing. No request is made. * ``unavailable`` — transport failure, a non-200, or a body this cannot parse. Only parsed fields are carried. The upstream body and its error text are logged (truncated) and dropped rather than returned — a caller is a tenant-facing endpoint, and there is no reason for a federal endpoint's response text to cross that boundary. It has to reach the log, though: a persistent ``unavailable`` is otherwise undiagnosable, and "the SPARQL no longer parses against a reshaped graph" and "the host is down" look identical from the outside. ⚠️ This docstring is **published** — it becomes the ``RegisterLookup`` schema description in ``openapi.json`` and the generated TS client's type docs. Keep it a statement about the wire contract; internal constant names do not belong in it.
  - `status` 'found' | 'not_found' | 'invalid' | 'unavailable', required
  - `name` string, nullable
  - `street` string, nullable
  - `postal_code` string, nullable
  - `city` string, nullable

## 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)