---
title: "Set Account Kind"
method: POST
path: "/api/account/kind"
tags: ["agents"]
---

# Set Account Kind

`POST /api/account/kind`

## Request

- Base URL: `https://api.parlel.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.parlel.com/api/account/kind`
- Auth: none declared

Say whether this account is a person or a company. Write-once-ish.

## Why it is not a settings toggle

The kind decides which public page an account owns: an individual gets a
``user_profiles`` row at ``/u/{handle}``, a company gets a ``companies`` row at
``/c/{handle}``. Switching therefore means abandoning one published page and
building another -- the old handle stays claimed by a row nothing in the new
shape reads, links to it keep resolving to a page the account is no longer
maintaining, and any roles hanging off a company become orphans of a company
the account has stopped being. That is a support conversation, not a radio
button, and every automatic resolution of it (delete the old page, migrate the
handle, keep both) is a decision this endpoint has no business making on
somebody's behalf.

## So the rule is: freely, until it has been used

Settable while the account has neither a profile nor a company row, which is
the whole of onboarding -- a user can pick "company", change their mind, and
pick "individual" as many times as they like before saving anything. The first
save of either page fixes it, and after that this returns 409 with a sentence
saying why.

Setting it to the value it already holds is always a 200 and writes nothing,
including after a page exists. A client that resends its current state on
every settings load must not be told it has a conflict with itself, and
"confirm what is already true" is not the operation this endpoint is
protecting against.

## Query cost

The two existence probes only run when the value is actually changing, so the
common no-op path costs one plan read and nothing else. Profiles are keyed by
``user_id``; companies are looked up by owner (``any_company_for``), since a
company row's primary key is now ``id``.

## Headers

- `authorization` string, nullable

## Request body

- AccountKindUpdate: Which front door this account came through. A ``Literal`` rather than a validated string, so an unknown value is a 422 naming both legal ones rather than a row in a state nothing in the product knows how to render.
  - `kind` 'individual' | 'company', required

## Response `200`

Successful Response

- object

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/parlel/apis/parlel-api.md) · [All operations](https://skmtc.dev/parlel/apis/parlel-api/llms.txt) · [OpenAPI document](https://skmtc.dev/parlel/apis/parlel-api/revisions/4d41a8f5cfc9?raw)
