---
title: "Sign My Agreement"
method: POST
path: "/api/asclepius/me/agreement/sign"
tags: ["asclepius"]
---

# Sign My Agreement

`POST /api/asclepius/me/agreement/sign`

## 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/me/agreement/sign`
- Auth: none declared

Take one signature and file the record.

The order of operations is the DLA's, and it is deliberate: verify the
affirmations and that the text has not changed underneath the signer, render
and store the PDF so a row can never point at a document that does not
exist, then INSERT the append-only row. A failure at the PDF step leaves
nothing signed.

SIGNING THE VERSION ALREADY SIGNED IS A 409, not an idempotent success. Two
rows for one version is a question somebody has to answer later, and a
physician who clicked twice needs to know the first click worked. Signing a
NEWER version is the normal path and writes a new row beside the old one.

## Headers

- `authorization` string, nullable

## Request body

- AgreementSignRequest: What a physician's clickwrap has to capture. No `authority_affirmed`: a physician binds themselves and there is nothing to have authority over. `signed_initials` takes its place as the act of signing, matching the onboarding form, where typing initials has always been what the copy calls an electronic signature.
  - `typed_name` string, required
  - `signed_initials` string, required
  - `consent_esign` boolean
  - `doc_sha256` 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)