π˜…π˜‚π—Ίπ—Ί for developers

π˜…π˜‚π—Ίπ—Ί for developers

Use the π˜…π˜‚π—Ίπ—Ί API to send payloads (sign requests) to app users.

Get Started    API Docs

Your first payload

The most basic payload you can POST to the https://xumm.app/api/v1/platform/payload endpoint only requires a valid TransactionType + the mandatory fields and values for the given transaction type. You can however leave out the fields that are client (signer) specific, like in this example (Payment) the "Account"-field, as the xumm app running on the device of the end user will fill that field based on the selected account used to sign.

{ 
  "txjson": {
    "TransactionType": "Payment",
    "Destination": "rPdvC6ccq8hCdPKSPJkPmyZ4Mi1oG2FFkT",
    "Fee": "12"
  }
}

Optionally, you can add the options and user_token keys to the payload data. TypeScript type definitions are available.

Exception on the default XRPL transaction format (JSON)

If maxLedgerSequence is entered with a value < 32570 xumm will handle and replace the value. It will be considered a relative value from the current ledger index at the moment the user taps the Accept (sign) button in xumm.

Read more about adding options and/or the user token in the API Docs

Using π˜…π˜‚π—Ίπ—Ί to sign in users

If you want to identify a user based on a signed transaction (without asking the user for a payment) you can send a payload with a false TransactionType.

By sending SignIn as the transaction type, xumm will show an alternative "sign in" screen. When the user signs, the transaction:

  • Will be signed
  • Will not be submitted to the XRPL
  • The signed transaction HEX will be delivered to your application (webhook / API call)

You can then use the signed HEX to verify the signature and identify the user. A sample payload for a sign in action could look something like this:

{ 
  "options": {
    "submit": false,
    "expire": 240,
    "return_url": {
      "app": "https://xrptipbot.com/signin?payload={id}",
      "web": "https://xrptipbot.com/signin?payload={id}"
    }
  },
  "user_token": "c5bc4ccc-28fa-4080-b702-0d3aac97b993",
  "txjson": {
    "TransactionType" : "SignIn"
  }
}

In this example, the user_token (if valid) will result in a direct push notification, with the sign request, to the end user. The sign in request will expire after 240 minutes, and the transaction will not be submitted ("submit": false) to the XRPL (as a SignIn transaction type does not exist on the XRPL).

A note on the return_url parameter

In the previous SignIn example, the given return_url for both app and web will redirect both the desktop browser flow (web) and the mobile (app) flow. In a real transaction scenario, only one of the two return URL's will most likely be entered.

If the user originates from a webapplication (desktop), the app return URL can be left out, so the user will return back home to the xumm app after signing, while the browser will redirect them back to your webapplication.

If the user originates from your own application, the web return URL can be left out, as the end user will be taken directly to the xumm app on their device, using the payload deep link, then returned to your application deep link.

Updated 4 days ago


Your first payload


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.