---
title: "Begin passkey enrollment for a connected user (always 403)"
method: POST
path: "/v1/platform/connections/{connectionId}/passkeys/enroll/begin"
tags: ["Platform"]
deprecated: true
---

# Begin passkey enrollment for a connected user (always 403)

`POST /v1/platform/connections/{connectionId}/passkeys/enroll/begin`

## Request

- Base URL: `https://api.1claw.co`
- URL: `https://api.1claw.co/v1/platform/connections/{connectionId}/passkeys/enroll/begin`
- Auth: HTTP bearer

> **Deprecated.**

**This endpoint always returns 403 and cannot be made to work.**
The description here previously said platform apps should use it
instead of `POST /v1/auth/passkeys/register/begin`, which was
wrong and cost integrators a WebAuthn ceremony to discover.

A passkey enrolled this way is login-capable: it can be asserted
through the public sign-in flow to mint a full, non-delegated
user session, so an app that enrolled one would hold a credential
stronger than the delegation boundary it operates under. The
capability was removed for that reason and will not return.

**A passkey is enrolled by the user, in their own session**, via
`POST /v1/auth/passkeys/register/begin`. For a connected user
that means completing the claim flow on the connection first.

To *use* a passkey a connected user already has, see:
  - `GET /v1/platform/connections/{connectionId}/passkeys` —
    whether the confirm step can be offered at all.
  - `POST /v1/platform/connections/{connectionId}/passkeys/tx-assert/begin`
    and `.../complete` — ask that user to touch their
    authenticator over a specific digest.

## Path parameters

- `connectionId` string, uuid, required

## Other responses

- `403`: Always. Platform apps cannot enroll login passkeys for connected users.

---

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