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. How to send the token on later calls is in Authenticating end users.

Request

Have the user’s wallet sign an empty intent, then send it as signedData. "intents": [] is the ownership proof. It does not move tokens. Field layout for each wallet is in Signing Intents. signer_id is the Intents account id for that key: The nonce has to be a versioned nonce. intentBuilder().setNonceRandomBytes(VersionedNonceBuilder.createTimestampedNonceBytes(new Date())) writes the current time into the first 8 bytes and loads the salt from intents.near (production salt e110f317). The server rejects a start time more than 5 minutes off with timestamp validation failed. A random 32-byte nonce comes back as invalid nonce. Send signatures as ed25519:<base58> or secp256k1:<base58>. For erc191 and tip191, the recovery byte is 0 or 1. Map wallet values 27 and 28 to 0 and 1 before you encode.
signature verification failed is the response when intents.near rejects the payload in simulate_intents. A signer_id that does not match the signing key, a recovery byte left at 27 or 28, or any difference between the signed string and the string you submit all return that same error.
standard is nep413. The NEP-413 message is the string below. recipient is intents.near.The signMessage callback returns a base64 signature. createIntentSignerNEP413 encodes it as ed25519: plus base58 before signed is sent.

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