Several AroPay endpoints return a .nota file: a serialized Notareum
resource. Think of it as a portable, typed envelope for payment artifacts:
instead of copy-pasting hex strings or screenshotting receipts, you exchange a
file that any Aro surface understands.All .nota endpoints return the same shape:
Any wallet (custodial or external) can produce an address card. Recipients
import it into any Aro recipient field (including
external wallet registration) instead of pasting an
address, eliminating transcription errors.
# Alice exports her card…curl -s "$BASE/wallets/$WALLET/nota" -H "Authorization: Bearer $ALICE_KEY" \ | jq -r .data.nota > alice.nota# …Bob registers it as a watch-only walletcurl -s "$BASE/wallets" -H "Authorization: Bearer $BOB_KEY" \ -H "content-type: application/json" \ -d "{\"type\":\"external\",\"nota\":\"$(cat alice.nota)\",\"label\":\"Alice\"}"
A malformed or wrong-type file is rejected with 400 invalid_nota.
Exporting a custodial key is deliberately guarded:
Session-only: API keys get 403 session_required; you must be signed
in to a browser session.
You supply a passphrase (8–200 characters); the key is encrypted
server-side with PBKDF2-SHA256 (310,000 iterations) + AES-256-GCM. The
plaintext key never crosses the wire.
Only custodial wallets can be exported; there is nothing to export for a
watch-only address.
See Export & backup for the full flow and
handling guidance.
Receipts are generated from on-chain state, so they exist only for
transactions that actually reached the chain. A transaction that is still
being submitted (or failed before submission) returns 400 until (unless)
it can be represented. For redeems, the receipt reflects both legs once
settled.
.nota content is opaque to the API consumer; treat it as a blob. Its
internal structure is a Notareum implementation detail and may evolve;
round-trip it through Aro surfaces rather than parsing it yourself.
⌘I
Assistant
Responses are generated using AI and may contain mistakes.