Record the browser device the caller is signed in from

Records a Fingerprint visitor id against an existing org. It exists because the dominant signup funnel is the first-login auto-onboard, which creates the org server-side with no request body to carry the device on, so without this endpoint the primary funnel would stay dark. Any member of the org may call it. It never changes access, billing, or org state, and it always returns 204 once authorized, including when the body is empty: a browser that blocked the agent must not see an error.

Authorization

apiKey

AuthorizationBearer <token>

OpenRelay API key. Send it as Authorization: Bearer or_… (legacy vl_… keys still work).

In: header

Path Parameters

orgId*string

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Browser signals the dashboard captured for this action: device intelligence from the Fingerprint JavaScript agent, and the reCAPTCHA v3 assessment of the same action. Every field is optional; a browser that blocked one vendor, both, or neither must reach the same 204. The two halves differ in what the server can do with them. The device fields are a CLAIM the control plane re-verifies with Fingerprint before it clusters on them. The captcha fields are a VERDICT the dashboard already reached against siteverify (a v3 token is single-use, so it cannot be re-checked here) and are recorded, never re-derived. The device half specifically: both fields are optional and CLIENT-REPORTED: the server records them and never refuses a request because of them or because they are missing. Send BOTH: the server checks the event id against Fingerprint's Server API, and only a confirmed pair is indexed, clustered, or used to raise a review flag. Anything it cannot confirm is kept as a claim and joins nothing (audit/FINGERPRINT.md).

deviceFingerprint?string

Fingerprint visitor id, the stable per-device identifier.

Lengthlength <= 128

deviceEventId?string

Fingerprint event id for this identification. It is the half the server verifies with Fingerprint (the visitor id alone cannot be), so a visitor id sent without it is recorded but never clustered.

Lengthlength <= 128

captchaScore?number

reCAPTCHA v3 score for the action behind this request, 0 to 1 ("1.0 is very likely a good interaction, 0.0 is very likely a bot", https://developers.google.com/recaptcha/docs/v3). The dashboard's server layer obtained it from Google's siteverify and checked the action, hostname, and challenge age before sending it, so this is a VERDICT the control plane records rather than a token it re-verifies. Absent when the feature is off or nothing could be measured, and an absent score is not a zero.

Range0 <= value <= 1

captchaBand?string

Which threshold band the score fell in: "pass" (>= 0.7), "step_up" (0.3 to 0.7), or "step_up_strict" (< 0.3). The step-up the band demanded has ALREADY been satisfied by the time the request arrives, so this records how much friction the customer met; it is never an instruction. A deployment with the feature off sends no captcha fields at all rather than a band meaning "we did not look" (docs/architecture/signup-bot-defense.md).

Lengthlength <= 32

captchaAction?string

The reCAPTCHA action the token was minted for (signup_password, signup_magic_link, signup_oauth, deposit, card_save). Already checked against siteverify's own action, which is what stops a token minted on the signup widget being replayed at the deposit endpoint.

Lengthlength <= 64

Response Body

`application/json`

curl -X POST "https://example.com/v1/orgs/string/device" \  -H "Content-Type: application/json" \  -d '{}'

Empty

Record the browser device the caller is signed in from

Authorization

Path Parameters

Request Body

Response Body

204

401application/json

403application/json

`application/json`

`application/json`