Robinhood Notifications: Onchain Alerts for Your App, Telegram, Email, and Phone

Robinhood Chain is on Tatum Notifications.

As of October 7, 2026, Robinhood mainnet accepts every alert type. Tatum POSTs the event to your webhook when it matches. The chain keeps moving. Your server hears about the transfers you asked for.

That webhook is also the way into an app, a Telegram chat, an inbox, or a phone. Tatum delivers JSON. Your server decides who else gets it.

What Robinhood Chain is doing

Robinhood Chain is an Ethereum Layer 2 built with Arbitrum Nitro. It is EVM compatible, so Solidity, viem, ethers, Hardhat, and Foundry all apply. Gas is ETH. Chain ID 4663. Public mainnet opened on July 1, 2026.

The earlier build guide covers RPC, websockets, and token reads. This one is the alert path: how to hear about an onchain event, then where to send it.

Chain snapshot

Robinhood Chain, mid-October 2026

DeFi TVL

$1.06B

Oct 12, 2026

Daily transactions

6.2M

Average, Oct 2 to 8

Spot DEX volume

$7.45B

That same week

Stablecoins

$1.10B

Supply, early October

Figures as of October 12, 2026. Daily transactions and spot volume cover October 2 to 8. Stablecoin supply is early October.

Activity cooled off a hot September. Daily transactions averaged 10.8 million from September 10 to 16, then 6.2 million from October 2 to 8. That is still a busy L2.

Money stayed. Deposits in lending and trading apps were about $1.04 billion. Stablecoin supply was about $1.10 billion. Spot exchanges cleared $7.45 billion that week, with Uniswap at about 77% of it. Rolling seven-day perpetual volume was about $7.35 billion, up 26%. Treat the cards as a snapshot. They will move.

At that pace, a loop that asks the node "anything new?" spends the day parsing other people's trades. An alert names the address, the token, and the size, and lets the rest of the block go by.

How an onchain alert is delivered

You create an alert with a chain, an address, a type, and an HTTPS URL. Tatum watches Robinhood Chain. When an event matches, it POSTs JSON to that URL. On EVM chains, the default trigger is one confirmation.

Create-alert pricing in the API reference is 50 credits per notification sent, plus 50 credits per day per alert. A narrow filter is cheaper than a firehose you discard in application code.

Pick an alert type

Robinhood mainnet is in the create-alert schema for the full set: address activity, native ETH, fungible tokens, NFTs, ERC-1155, internal transfers, fees, mints, burns, decoded Uniswap v2 and v3 swaps, contract logs, and failed transactions. The chain slug is robinhood-mainnet.

Specific types are the quieter choice. INCOMING_FUNGIBLE_TX on a treasury beats ADDRESS_EVENT plus a filter you could have declared up front. Use the wide type when you truly want every touch of the address.

robinhood-mainnet

The full set

Sample: INCOMING_FUNGIBLE_TX, 1,000 tokens, confirmed

All 18 Wallets Tokens Contracts

Type	Fires when	Reach for it when
ADDRESS_EVENT	Any activity on the address	One subscription for the whole wallet
INCOMING_NATIVE_TX	ETH arrives	A deposit ping
OUTGOING_NATIVE_TX	ETH leaves	A withdrawal ping
INCOMING_INTERNAL_TX	Value arrives through an internal call	A contract payout
OUTGOING_INTERNAL_TX	Value leaves through an internal call	Outflows a top-level transfer would miss
PAID_FEE	The address pays gas	Fee accounting
OUTGOING_FAILED_TX	An outgoing transaction reverts	A send that did not land
INCOMING_FUNGIBLE_TX	An ERC-20 arrives	Token or stock-token deposits
OUTGOING_FUNGIBLE_TX	An ERC-20 leaves	Token sends
INCOMING_NFT_TX	An ERC-721 arrives	NFT receipts
OUTGOING_NFT_TX	An ERC-721 leaves	NFT sends
INCOMING_MULTITOKEN_TX	An ERC-1155 arrives	Multi-token receipts
OUTGOING_MULTITOKEN_TX	An ERC-1155 leaves	Multi-token sends
MINT_TX	Tokens are minted to the address	New supply landing in the wallet
BURN_TX	Tokens are burned from the address	Supply destroyed from that wallet
SWAP_TX	A decoded Uniswap v2 or v3 swap	The address bought or sold
CONTRACT_ADDRESS_LOG_EVENT	A contract log you name	Custom events, past plain transfers
FAILED_TXS_PER_BLOCK	Failed transactions in a block	Revert watch across the chain

18 alert types on robinhood-mainnet. The sample line is illustrative.

Address alerts are unique per API key on type + chain + address + url. Contract-log alerts add the contract and the event name. Block alerts are unique on type + chain + url. A second filter on the same address needs a different webhook URL, or the create call is rejected.

Create the alert

Robinhood Chain

Your dashboard view

Chain

Robinhood ChainMainnet · robinhood-mainnet

Type

Address activity Incoming token Incoming ETH Swap Contract log

Address Destination

Finality

confirmed final

Template enriched enriched_with_raw_data legacy

Create alert

dashboard.tatum.io/notifications/alerts/create

With the API

The create an alert call is POST /v4/subscription. finality and templateId sit next to type. The address, chain, URL, and conditions sit inside attr. Pass ?type=mainnet so the call uses your mainnet key.

curl -X POST 'https://api.tatum.io/v4/subscription?type=mainnet' \
  -H 'content-type: application/json' \
  -H 'x-api-key: YOUR_API_KEY' \
  -d '{
    "type": "ADDRESS_EVENT",
    "attr": {
      "chain": "robinhood-mainnet",
      "address": "0xYourTreasury",
      "url": "https://your-app.com/webhooks/robinhood"
    },
    "finality": "confirmed",
    "templateId": "enriched"
  }'

The response is an id. Store it. You will need it to update or cancel the alert.

{ "id": "6644ce703ac81e0b215820cc" }

Cancel it with DELETE /v4/subscription/{id} and the same x-api-key header. List what you already created with GET /v4/subscription.

An enriched webhook wraps the event in data. Count on from, to, value, txId, currency, subscriptionType, and tokenMetadata when the asset has metadata. The templates reference has the full JSON. Log the first live payload before you turn value into a balance.

Conditions, finality, and templates

Three knobs decide what reaches your URL, when it arrives, and which fields show up. They are available on Robinhood because it is an EVM chain on Notifications v4.

On the alert

What you can control

Amount, token, sender Amount, token contract, sender, recipient, token id, and symbol. Every condition must match. A 12-unit dust transfer never hits the URL. A 1,000-unit deposit of the token you named does. When it sends confirmed sends when the transaction is confirmed. final waits for confirmation depth. Use confirmed to move a balance in the UI. Use final before you credit a user or release treasury funds. Payload shape enriched is the one to start with. You can also ask for raw data, legacy fields, or your own names. Your app, Telegram text, and email body can all read the same shaped JSON.

Filter by amount, token, sender, or recipient

Conditions live in attr.conditions. Each one is a field, an operator, and a string value. All of them have to match. Fields: value, contractAddress, from, to, tokenId, tokenMetadata.type, tokenMetadata.symbol. Operators: >, >=, <, <=, ==, !=.

Amounts are human-readable. In the conditions guide, "1" means 1 ETH and "1000" means 1,000 of the token. Pass the number as a string.

This alert fires for incoming transfers of one token, at or above 1,000 units, and waits for final. Look the contract up on Blockscout and paste that address. The URL is different from the catch-all alert above, because uniqueness includes the URL.

{
  "type": "INCOMING_FUNGIBLE_TX",
  "attr": {
    "chain": "robinhood-mainnet",
    "address": "0xYourTreasury",
    "url": "https://your-app.com/webhooks/robinhood-large",
    "conditions": [
      { "field": "contractAddress", "operator": "==", "value": "0xYourToken" },
      { "field": "value", "operator": ">=", "value": "1000" }
    ]
  },
  "finality": "final",
  "templateId": "enriched"
}

A sender filter uses from. A recipient filter uses to. Updating an existing alert is PUT /v4/subscription/{id} with a new conditions array. That array replaces the old one. An empty array clears the filter.

Choose confirmed or final

finality is confirmed or final. Confirmed is the fast path: the transaction is onchain, and the webhook goes out. Final waits for the chain's confirmation depth. A live portfolio can use confirmed. A credit to a user balance, or a treasury move, should use final.

Robinhood Chain can still reorg like any EVM chain. The workflow guide is the reference for those two values. If a later block replaces the one you already acted on, your handler needs a way to reverse a confirmed credit. Final is how you avoid that job for money movement.

Shape the webhook

Omit templateId and you get the legacy flat payload (amount, address, counterAddress, txId). enriched is the recommended shape, with token metadata. enriched_with_raw_data adds the raw log. A custom id uses a template you created.

Create a template at POST /v4/subscription/template, then pass the returned id:

{
  "format": "json",
  "keys": {
    "amount": "value",
    "sentFrom": "from",
    "sentTo": "to",
    "tx": "txId"
  }
}

The webhook then arrives with your names. Template docs cover list, update, and delete.

App, Telegram, email, phone

The webhook is the handoff. Your handler checks the signature, answers 200, then fans the event out. Telegram, email, and SMS are the next calls that handler makes. That is the whole setup for an app, a chat, an inbox, or a phone.

Turn HMAC on once per API key. Each webhook then carries x-payload-hash. Rebuild it as HMAC SHA-512 over JSON.stringify(body), base64, and compare. The authentication guide has the enable call and a worked example. IP allowlists exist, and the same guide says HMAC is the check to rely on.

curl -X PUT 'https://api.tatum.io/v4/subscription' \
  -H 'content-type: application/json' \
  -H 'x-api-key: YOUR_API_KEY' \
  -d '{ "hmacSecret": "YOUR_HMAC_SECRET" }'

Same webhook

Where the alert goes next

Your app Telegram Email Phone

Verify the hash, store the txId, return 200. Do the database write after the response if it might be slow. Tatum retries failed deliveries, and a slow 200 looks like a failure.

JavaScript

import { createHmac } from 'node:crypto'

function signatureOk(body, header) {
  const digest = createHmac('sha512', process.env.TATUM_HMAC_SECRET)
    .update(JSON.stringify(body))
    .digest('base64')
  return digest === header
}

export async function POST(request) {
  const body = await request.json()
  const header = request.headers.get('x-payload-hash')
  if (!signatureOk(body, header)) {
    return new Response('invalid signature', { status: 401 })
  }
  const transfer = body.data ?? body
  await saveEvent(transfer.txId, transfer)
  return new Response('ok', { status: 200 })
}

Create a bot with BotFather, message it once, and read the chat id from getUpdates. Keep the bot token on the server. The handler sends a text message after the signature check.

JavaScript

const transfer = body.data ?? body
const text = [
  'Robinhood Chain',
  transfer.subscriptionType,
  transfer.value,
  transfer.tokenMetadata?.symbol || transfer.currency || '',
  transfer.txId
].filter(Boolean).join(' ')

await fetch(
  'https://api.telegram.org/bot' + process.env.TELEGRAM_BOT_TOKEN + '/sendMessage',
  {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({
      chat_id: process.env.TELEGRAM_CHAT_ID,
      text
    })
  }
)

Email is another call from that same handler. Resend is one option. Amazon SES and Postmark take the same idea: your server sends the mail, Tatum does not.

JavaScript

await fetch('https://api.resend.com/emails', {
  method: 'POST',
  headers: {
    authorization: 'Bearer ' + process.env.RESEND_API_KEY,
    'content-type': 'application/json'
  },
  body: JSON.stringify({
    from: 'alerts@yourapp.com',
    to: ['ops@yourapp.com'],
    subject: 'Robinhood Chain alert',
    text
  })
})

A phone gets an SMS, or a push if the person is in your app. SMS below uses Twilio. For a product, send the push through FCM or APNs from this handler and keep SMS for the ops number.

JavaScript

const auth = Buffer.from(
  process.env.TWILIO_ACCOUNT_SID + ':' + process.env.TWILIO_AUTH_TOKEN
).toString('base64')

await fetch(
  'https://api.twilio.com/2010-04-01/Accounts/' +
    process.env.TWILIO_ACCOUNT_SID +
    '/Messages.json',
  {
    method: 'POST',
    headers: {
      authorization: 'Basic ' + auth,
      'content-type': 'application/x-www-form-urlencoded'
    },
    body: new URLSearchParams({
      To: process.env.ALERT_PHONE,
      From: process.env.TWILIO_FROM,
      Body: text
    })
  }
)

One handler can do all four. Check the signature, ack, then notify the app, the chat, the inbox, and the phone from the jobs you actually want. Deduplicate on txId plus the subscription id so a retry does not send a second text.

RPC and the Data API

The alert tells you something happened. RPC and the Data API are how you read the chain around it. Both cover Robinhood mainnet and testnet. The notification chain slug on this launch is robinhood-mainnet.

Gateway hosts, from the Robinhood RPC reference:

• Mainnet JSON-RPC: https://robinhood-mainnet.gateway.tatum.io
• Mainnet websocket: wss://robinhood-mainnet.gateway.tatum.io
• Testnet JSON-RPC: https://robinhood-testnet.gateway.tatum.io
• Testnet websocket: wss://robinhood-testnet.gateway.tatum.io

A connectivity check is the latest block. Send the API key in x-api-key.

curl https://robinhood-mainnet.gateway.tatum.io/ \
  -H 'content-type: application/json' \
  -H 'x-api-key: YOUR_API_KEY' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

When the webhook arrives, two Data API reads fill in the rest. Portfolio is the current fungible balances. Transaction history is the indexed transfer, which you can narrow with transactionTypes and transactionSubtype. Swap robinhood-mainnet for robinhood-testnet while you are building the reader.

curl 'https://api.tatum.io/v4/data/wallet/portfolio?chain=robinhood-mainnet&addresses=0xYourTreasury&tokenTypes=fungible' \
  -H 'x-api-key: YOUR_API_KEY'

curl 'https://api.tatum.io/v4/data/transaction/history?chain=robinhood-mainnet&addresses=0xYourTreasury&transactionTypes=fungible&transactionSubtype=incoming&pageSize=10' \
  -H 'x-api-key: YOUR_API_KEY'

Use RPC when you need the receipt (eth_getTransactionReceipt), a contract read (eth_call), a log query (eth_getLogs), or a signed send (eth_sendRawTransaction). Use the websocket when a screen wants a live block. Use the alert when the product needs to know that a specific wallet moved.

Testnet is the right place to wire the portfolio and history screens. The alert itself goes on mainnet, against an address you control. Send a small token transfer, confirm the POST, then turn on Telegram or SMS.

Frequently asked questions

Click a question to open the answer.