Skip to main content
POST
Authenticate user with signed data
Send this endpoint a signed message from your user, and you’ll get back a User-Session token. That token is what lets the user’s confidential balances and transaction history (GET /v0/account/balances, GET /v0/account/history) be revealed. It’s separate from your Partner JWT, which authenticates your integration, not an individual user.
This is part of Confidential Intents. See Authenticating end users for the full guide.

Getting a signature to send

Your user’s NEAR wallet produces public_key and signature. The steps:
  1. Build a NEP-413 payload: recipient set to "intents.near", a fresh random nonce, and message set to a stringified JSON object with an empty intents array plus a deadline and the user’s signer_id. The empty intents array is what makes this a proof of ownership instead of a real swap.
  2. Have the user’s wallet sign that payload. The wallet returns the publicKey that signed it and the resulting signature, both prefixed ed25519:.
  3. Send payload, public_key, and signature together as signedData on this endpoint.
If you’re on @defuse-protocol/intents-sdk, createIntentSignerNEP413 and buildAndSign() do steps 1 and 2 for you, that’s what the TypeScript SDK example below uses.

Example request

Example response

signedData is the same MultiPayload signed-message format used for Signing Intents, signed here with an empty intents array. It’s used purely as proof of account ownership, not a real swap.
Store refreshToken securely. Anyone holding it can mint new accessTokens for this account until it expires.

Body

application/json
signedData
object
required

Assuming wallets want to interact with Intents protocol, besides preparing the data in a certain form, they have to have the capability to sign raw messages (off-chain signatures) using an algorithm we understand. This enum solves that problem.

For example, because we support ERC-191 and know how to verify messages with that standard, we can allow wallets, like Metamask, sign messages to perform intents without having to support new cryptographic primitives and signing standards.

Response

accessToken
string
required

JWT access token for API calls

refreshToken
string
required

JWT refresh token for getting new access tokens

expiresIn
number
required

Access token expiration time in seconds

refreshExpiresIn
number
required

Refresh token expiration time in seconds