---
title: "Hs Signup"
method: POST
path: "/api/asclepius/hs/signup"
tags: ["asclepius-provider"]
---

# Hs Signup

`POST /api/asclepius/hs/signup`

## Request

- Base URL: `https://app.archangelhealth.ai` (the document declares no server; this is the origin it was published from)
- URL: `https://app.archangelhealth.ai/api/asclepius/hs/signup`
- Auth: none declared

Stage a signup and mail a code. Creates no account.

The guard stack is the one ``/api/onboarding/self-serve`` already runs, in
the same order: IP limit, global cap, honeypot, per-address cap, then proof
of the mailbox. It diverges in one place, deliberately. Onboarding answers
an over-cap address with a 429 whose text confirms we have seen it before;
here every outcome returns the same body, because this file's standing rule
is one code path with one observable, and ``hs_login`` two hundred lines up
goes to considerable trouble for exactly that property. Losing it on the
signup route would be an odd place to stop caring.

The send is awaited, which the authenticated routes below must not do. It is
correct here: no session exists yet, so response time correlates with
nothing about an existing partner, and the person genuinely needs to be told
if the code could not be sent.

## Request body

- HsSignupRequest
  - `full_name` string, required
  - `email` string, required
  - `organization` string, required
  - `password` string
  - `company_website` string

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/archangelhealth/apis/archangel-health-surgical-patient-platform.md) - [All operations](https://skmtc.dev/archangelhealth/apis/archangel-health-surgical-patient-platform/llms.txt) - [OpenAPI document](https://skmtc.dev/archangelhealth/apis/archangel-health-surgical-patient-platform/revisions/3514f4e119da?raw)
