Documentation Index
Fetch the complete documentation index at: https://docs.portalhq.io/llms.txt
Use this file to discover all available pages before exploring further.
What’s an alert webhook?
Alert webhooks can send you realtime wallet notifications for your clients. For example, they can be useful for receiving notifications when your clients receive or send EVM transactions. Alert webhooks are easily configured in the Portal Admin Dashboard. If you don’t see “Alert Webhooks” in the Portal Admin Dashboard, reach out to our team and we can enable the feature for you.Configuring alert webhooks
- Reach out to our support team and we can enable alert webhooks for your organization.
- Navigate to
"Configuration">"Webhooks"in the Portal Admin Dashboard and under the"Alert Webhooks"section, click"New +". - Enter your alert webhook URL.
- Select the events you want to receive (e.g.
EVM Wallet Transactions). - Save your configuration.
Take note of the IP addresses listed on this modal. You can add them to your allowlist to ensure you’re only accepting requests from Portal.
External addresses
External addresses let you receive alert webhook notifications for blockchain addresses that weren’t generated by Portal — such as treasury wallets, exchange deposit addresses, or other addresses you want to monitor. Portal supports external addresses on EVM (EIP-155) and Solana namespaces.Adding external addresses via the Dashboard
- Navigate to
"Configuration">"Webhooks"in the Portal Admin Dashboard. - Below the
"Alert Webhooks"section, find the"External Addresses"section. - Click
"Add". - Select a namespace (
eip155orsolana). - Enter the address you want to monitor.
Adding external addresses via the API
You can also manage external addresses programmatically using the Custodian API:- Create:
POST /custodians/me/alerts/webhooks/external-addresses - List:
GET /custodians/me/alerts/webhooks/external-addresses - Delete:
DELETE /custodians/me/alerts/webhooks/external-addresses/{externalAddressId}
address and a namespace:
"solana" as the namespace:
Addresses are validated for correct format based on the selected namespace. Blackhole addresses (such as null or dead addresses) are rejected.
Types of alerts
EVM Wallet Transactions
Immediately after configuring the alert webhook with EVM Wallet Transactions selected as an event, Portal starts to listen for any inbound/outbound EIP-155 transactions, approvals, and revocations for your clients that have an EIP-155 address. From then on when you create a new client with an EIP-155 address, Portal will notify you of their on-chain transactions.
When an EVM transaction occurs, Portal makes a POST request to your configured alert webhook URL with a request body that contains the alert webhook event’s details. You will receive 2 alerts per transaction — The first alert is unconfirmed and, once the transaction receives sufficient confirmations, the second alert is confirmed.
EVM Wallet Transactions currently sends alerts with the following use cases:- Receive native tokens (ie.
ETH) from another address - Send native tokens (ie.
ETH) to another address - Receive non-native tokens (ie.
USDC) from another address - Send non-native tokens (ie.
USDC) to another address - Approve non-native tokens (ie. approve
USDCfor a spender) - Revoke non-native token approvals (ie. set a spender’s allowance to 0)
When a block is unconfirmed, chain reorganizations may occur. If a reorganization happens, the original block’s data is replaced with the updated block. This means you might receive an
unconfirmed alert without a subsequent confirmed alert for the same transaction if this happens.EVM Wallet Transactions alerts.
| Name | Chain ID | Blocks until confirmed |
|---|---|---|
| Ethereum | eip155:1 | 12 |
| Ethereum Sepolia | eip155:11155111 | 18 |
| Polygon | eip155:137 | 100 |
| Polygon Amoy | eip155:80002 | 100 |
| Arbitrum | eip155:42161 | 18 |
| Arbitrum Sepolia | eip155:421614 | 600 |
| Optimism | eip155:10 | 500 |
| Optimism Sepolia | eip155:11155420 | 600 |
| Base | eip155:8453 | 100 |
| Base Sepolia | eip155:84532 | 100 |
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
- Receive ETH
- Send ETH
- Receive USDT
- Send USDT
- Approve token
- Revoke approval
Unconfirmed alert:Confirmed alert:
actualGasCost and formattedActualGasCost are only populated for clients whose custodian has Account Abstraction enabled, and only when the transaction was executed as a user operation. actualGasCost is a hex-encoded Wei amount (with 0x prefix); formattedActualGasCost is the same value as a base-10 Wei string. When a gas policy is enabled for the chain, these values reflect the gas you sponsored for that user operation.Solana Wallet Transactions
Once you set up an alert webhook with Solana Wallet Transactions as the event, Portal begins monitoring transfer transactions for your Portal clients with a Solana address. Any new client created with a Solana address will also trigger notifications for their on-chain transfers. Portal sends one event per subscribed address involved in the transaction, identified by a triggeredBy field on the payload.
When a Solana transfer transaction occurs, Portal makes a POST request to your configured alert webhook URL with a request body that contains the alert webhook event’s details. You will receive 1 alert per subscribed address involved when the transaction is confirmed.
Still on the legacy Solana alert webhook events? See
Solana Wallet Transactions (Legacy) and the migration guide.Direction
Every Solana alert webhook event includes adirection field that describes what the triggeredBy address did in the transaction. Use it together with triggeredBy to route events without re-deriving the role from the raw transaction data.
| Value | Meaning |
|---|---|
OUTBOUND | triggeredBy is the sender of the transaction — the one who sent native or non-native tokens, who approved or revoked a delegation, or who executed a delegated transfer. |
INBOUND | triggeredBy is the receiver of the transaction — the one who received tokens, or who was granted approval to spend delegated tokens. |
DELEGATED | Only on Solana Delegated Transfers events: triggeredBy is the owner whose tokens are being moved by the delegate (the source of funds in the delegated transfer, distinct from the delegate that executed it). |
Solana Wallet Transactions currently sends alerts for non-delegated transactions with the following use cases:- Receive native tokens (ie.
SOL) from another address - Send native tokens (ie.
SOL) to another address - Receive non-native tokens (ie.
USDC) from another address - Send non-native tokens (ie.
USDC) to another address
Solana Delegated Transfers.Solana alert webhook events support up to 1,000,000 addresses. Contact our team if you require additional capacity.
Retry schedule
| Retry | Backoff |
|---|---|
| 1 | 4 minutes |
| 2 | 8 minutes |
| 3 | 15 minutes |
| 4 | 30 minutes |
| 5 | 1 hour |
| 6 | 2 hours |
| 7 | 4 hours |
| 8 | 8 hours |
| 9 | 16 hours |
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
- Receive 0.01 SOL
- Send 0.0002 SOL
- Receive 0.0001 USDC
Solana Token Approvals
Once you configure an alert webhook with Solana Token Approvals selected as an event, Portal sends a notification any time a Portal client approves a delegated address to spend an amount of a token on their behalf for the specified chain. Portal delivers one event per subscribed address involved and includes a direction field — OUTBOUND for the owner approving the delegation, INBOUND for the delegate being approved to spend.
When a token approval occurs, Portal makes a POST request to your configured alert webhook URL with a request body that contains the alert webhook event’s details. You will receive 1 alert per subscribed address involved when the transaction is confirmed.
Headers:
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
Solana Token Revocations
Once you configure an alert webhook with Solana Token Revocations selected as an event, Portal sends a notification any time a Portal client revokes a delegated address’s approval to spend an SPL token on their behalf for the specified chain. Portal delivers one event per subscribed address involved and includes a direction field, which is always OUTBOUND for revocations.
When a token revocation occurs, Portal makes a POST request to your configured alert webhook URL with a request body that contains the alert webhook event’s details. You will receive 1 alert per subscribed address involved when the transaction is confirmed.
Headers:
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
Solana Delegated Transfers
Solana Delegated Transfers triggers when a user performs a delegated transfer using funds from another user who has approved a token delegation to them.
This event type is useful for tracking when delegated token allowances are actually spent. For example, if User A approves User B to spend their USDC, and User B later transfers some of User A’s USDC, you will receive a SOLANA_DELEGATED_TRANSFER_V2 event.
Each event carries a direction field that distinguishes the three roles in a delegated transfer: OUTBOUND for the delegate who executed the transfer, INBOUND for the recipient of the tokens, and DELEGATED for the owner whose tokens were moved. This is the only Solana event where direction can be DELEGATED.
Once you configure an alert webhook with Solana Delegated Transfers selected as an event, Portal sends a notification any time a delegated transfer occurs involving your Portal clients.
When a delegated transfer occurs, Portal makes a POST request to your configured alert webhook URL with a request body that contains the alert webhook event’s details. You will receive 1 alert per subscribed address involved when the transaction is confirmed.
Headers:
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
Wallet Ejected
Once you configure an alert webhook with Wallet Ejected selected as an event, Portal will send you notifications whenever one of your Portal clients ejects their wallet. When a wallet ejection occurs, Portal makes a POST request to your configured alert webhook URL with a request body that contains the clientId of the Portal client who ejected their wallet, as well as the clientPlatform and clientPlatformVersion of the client if available.
Regardless of your API response, the eject operation has already been processed for the Portal client who ejected their wallet.
Headers:
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
Signature Approvals
After enabling Signature Approvals, Portal will make a request to your configured alert webhook URL any time that one of your Portal wallets attempt to sign. This request will contain the chainId, clientId, and signingRequest, which you can use to derive if the signing request should be allowed to continue.
You must respond with a status code of 200-299 for the signing request to continue. To deny the request, you must respond with a 400 status code. If any other status code is received, or if 30 seconds passes with no response from your API, we will deny the signing request.
Headers:
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
- EVM
- Solana
- Tron
- Stellar
Solana Alert Webhook Events (Legacy)
Already integrated against the V1 events below? Follow the migration guide for legacy Solana alert webhook events to move to the current alerts and to subscribe to the new
Solana Delegated Transfers event.Why migrate from V1 to V2?
We recommend moving from V1 to the current Solana alert webhook events. V1 will be deprecated in the near future, and the current events give you per-address delivery (with atriggeredBy field for routing), a direction field for parsing the role of each address, and the new Solana Delegated Transfers event for tracking delegate spends. See the migration guide for legacy Solana alert webhook events for the cutover steps.
| V1 | V2 | |
|---|---|---|
| Delivery model | One event per Solana transaction | One event per subscribed address involved in the transaction |
| Address identification | No triggeredBy field | Includes triggeredBy — the address that triggered the event |
| Direction parsing | No direction field | Includes direction (OUTBOUND, INBOUND, or DELEGATED) |
| Delegated transfers | Not delivered as a separate event | New Solana Delegated Transfers event when a delegate spends an approved allowance |
| Event type | SOLANA_TX_V1 | SOLANA_TX_V2 |
triggeredBy value. You can use the triggeredBy field along with the transaction signature to deduplicate events on your end if needed.
Solana Wallet Transactions (Legacy)
Once you set up an alert webhook with Solana Wallet Transactions as the event, Portal begins monitoring transfer transactions for your Portal clients with a Solana address. Any new client created with a Solana address will also trigger notifications for their on-chain transfers.
When a Solana transfer transaction occurs, Portal makes a POST request to your configured alert webhook URL with a request body that contains the alert webhook event’s details. You will receive 1 alert when the transaction is confirmed.
Solana Wallet Transactions currently sends alerts with the following use cases:- Receive native tokens (ie.
SOL) from another address - Send native tokens (ie.
SOL) to another address - Receive non-native tokens (ie.
USDC) from another address - Send non-native tokens (ie.
USDC) to another address
Solana alert webhook events support up to 100,000 addresses. Contact our team if you require additional capacity.
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
- Receive 0.01 SOL
- Send 0.0002 SOL
- Receive 0.1 USDC
- Send 0.01 USDC
Solana Token Approvals (Legacy)
Once you configure an alert webhook with Solana Token Approvals selected as an event, Portal sends a notification any time a Portal client approves a delegated address to spend an amount of a token on their behalf for the specified chain.
When a token approval occurs, Portal makes a POST request to your configured alert webhook URL with a request body that contains the alert webhook event’s details. You will receive 1 alert when the transaction is confirmed.
Headers:
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
Solana Token Revocations (Legacy)
Once you configure an alert webhook with Solana Token Revocations selected as an event, Portal sends a notification any time a Portal client revokes a delegated address’s approval to spend an SPL token on their behalf for the specified chain.
When a token revocation occurs, Portal makes a POST request to your configured alert webhook URL with a request body that contains the alert webhook event’s details. You will receive 1 alert when the transaction is confirmed.
Headers:
| Name | Type | Description |
|---|---|---|
Content-Type | String | application/json |
X-WEBHOOK-SECRET | String | You can find the alert webhook secret in the Portal Admin Dashboard on the "Webhooks" page under the "Alert Webhooks" section. |
Security
Here are a few considerations to ensure your alert webhooks are implemented securely:- Alert webhook URLs must use
HTTPS. - Verify that each alert webhook request has the expected
X-WEBHOOK-SECRETheader value. You can find the secret for your alert webhook in the Portal Admin Dashboard. - Restricting requests on your alert webhook server to only those from Portal’s IP addresses protects against requests from other parties. Configure your alert webhook server to only accept inbound connections from our IP addresses. Portal always makes requests from the IP addresses
35.203.150.117,104.155.171.139or35.185.20.23.
Example Implementation
We provide a reference implementation of alert webhooks using TypeScript and Express. This example demonstrates best practices for handling alert webhook events, including:- 🔒 IP address verification
- 🔑 Webhook secret validation
- ⚡ Async event processing
FAQ
What if I miss an alert webhook event?
- If your alert webhook is down or is not responding with
2xxstatus codes, Portal will retry sending the alert webhook event.- For Solana alert webhook events V1, we retry once every minute for 3 minutes.
- For Solana alert webhook events V2, we retry using an exponential backoff with up to 9 retries. See the retry schedule for details.
- For EIP-155 webhook events, we retry 6 times progressively over 24 hours.
- If your EIP-155 alert webhook fails to receive the event:
- You can find all of your alert webhooks using this endpoint.
- You can then find an alert webhook’s associated events using this endpoint.
- You can replay the exact alert webhook event that failed to be delivered using this endpoint.
Should I process webhook events before responding?
No. Please acknowledge webhooks as quickly as possible. If you need to process the alert webhook event you receive, process it after responding to Portal with a2xx status code. (We only wait up to 10 seconds to receive a response before considering the alert webhook event’s delivery as failed.)