Account
Account

Sign-in by email — step B: the wallet consents

Called from the device logged in WITH THE EXECUTOR'S WALLET. The wallet signs EXACTLY (/login-email/preview returns it ready):

Execution Market: allow sign-in by email <email_hint> for executor <executor_id> wallet <wallet> with code <CODE> at <ISO8601 UTC>

<email_hint> is the code's masked email, <wallet> lowercase, <CODE> uppercase without spaces, timestamp within the last 10 minutes. <executor_id> must be an executor bound to this session. 65-byte signatures are EIP-191; any other length is verified via ERC-1271 like link-wallet. The code is single-use, lives 10 minutes, and 5 rejected consents invalidate it. The pairing is born PENDING: the email side accepts this wallet on /login-email/resume. A session that was itself opened by email gets 403.

post/api/v1/account/login-email/confirm

Request

  • Base URL: https://api.execution.market
  • URL: https://api.execution.market/api/v1/account/login-email/confirm
  • Auth: API key in header Signature-Input

Headers

authorizationstring nullable

Bearer <supabase_jwt>

Request body

codestring required

The code shown on the email session (case, spaces and dashes are ignored)

messagestring required

Exactly: Execution Market: allow sign-in by email <email_hint> for executor <executor_id> wallet <wallet lowercase> with code <CODE uppercase> at <ISO8601 UTC>, timestamp within the last 10 minutes. <email_hint> is the code's own (see /login-email/preview, which returns this message ready to sign).

signaturestring required

Signature of message by the executor's wallet. 65 bytes = EIP-191 (ecrecover); any other length = smart wallet, verified on-chain via ERC-1271 like link-wallet.

Response

Successful Response

link_idstring required
executor_idstring required
wallet_addressstring required

The wallet that consented (lowercase)

email_hintstring nullable

Masked email, e.g. s***@g***.com

created_atstring required
relinkedboolean required

True when this Dynamic user was already paired with THIS executor and the pairing was refreshed (new email hash and consenting wallet)

accepted_atstring nullable

Always null here: the pairing is PENDING until the email side accepts this wallet on /login-email/resume (accept_wallet)

Changes

No recorded changes to this operation across all 1 revision of this API.