The current Solana alert webhooks supersede the legacy ones. They change the delivery model from “one event per transaction” to “one event per address involved”, and introduce a new event type for delegated transfers along with two new payload fields (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.
triggeredBy and direction). This guide is for customers still consuming the legacy Solana alerts who want to migrate.
What’s changing
-
Per-address delivery. The legacy webhook sent a single event per Solana transaction. The new webhook sends one event per subscribed address involved in the transaction. If two of your Portal clients are involved in a single Solana transaction (e.g. one sends SOL to the other), you will now receive two webhook events for that transaction — each with a different
triggeredByvalue and the samesignature. -
New event types. Each legacy event type has a replacement, plus a brand-new event for delegated transfers:
SOLANA_TX_V2— Solana native (SOL) transfers and SPL token transfers. (ReplacesSOLANA_TX_V1, without delegated transfers.)SOLANA_APPROVE_V2— Solana delegation approve transactions. (ReplacesSOLANA_APPROVAL_V1.)SOLANA_REVOKE_V2— Solana delegation revoke transactions. (ReplacesSOLANA_REVOKE_V1.)SOLANA_DELEGATED_TRANSFER_V2— New event. Fires when a delegate executes a transfer using funds from another user’s previously-approved delegation.
-
triggeredByfield. Every event payload now includes atriggeredByfield. It identifies which of your subscribed addresses caused this specific event delivery. Use this to route events to the right user/account on your side without re-deriving it from the raw transaction data. -
directionfield. Every event payload also includes adirectionfield that describes what thetriggeredByaddress did in the transaction:Value Meaning OUTBOUNDtriggeredByis 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.INBOUNDtriggeredByis the receiver of the transaction — the one who received tokens, or who was granted approval to spend delegated tokens.DELEGATEDOnly on SOLANA_DELEGATED_TRANSFER_V2events:triggeredByis 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).
Payload differences
The same Solana transfer (a 0.01 SOL receive) shows up like this on the legacy webhook vs the new one. Note the newtriggeredBy and direction fields, and the type value changing from SOLANA_TX_V1 to SOLANA_TX_V2.
- Legacy payload
- New payload
Event payloads
Below is a full example payload for each new event type so you can wire up parsers and types ahead of cutting over.SOLANA_TX_V2
SOLANA_APPROVE_V2
SOLANA_REVOKE_V2
SOLANA_DELEGATED_TRANSFER_V2
Migration steps
-
Expect multiple events per transaction. If two or more of your subscribed addresses are involved in the same Solana transaction, you will receive one event per address. Update your event handlers to be safe under this fan-out.
- Idempotency between transactions: dedupe on the
signaturefield. Solana transactions are uniquely identified by theirsignature, so it works as a stable idempotency key for “have I seen this transaction before?”. - Idempotency per (transaction, address): dedupe on the composite key
signature+triggeredBy. Use this when you process events per-address, so each(transaction, address)pair is processed exactly once even if the webhook is retried.
- Idempotency between transactions: dedupe on the
-
Subscribe to the events you need from the Portal Admin Dashboard. In the Alert Webhooks settings, select the event types your integration cares about:
SOLANA_TX_V2,SOLANA_APPROVE_V2,SOLANA_REVOKE_V2, and/orSOLANA_DELEGATED_TRANSFER_V2.If you want to keep parity with the legacy webhook — i.e. be notified about every transfer involving your addresses — subscribe to bothSOLANA_TX_V2andSOLANA_DELEGATED_TRANSFER_V2. WithoutSOLANA_DELEGATED_TRANSFER_V2, transfers executed by a delegate against an approval that one of your addresses granted will not generate any webhook event. -
Test that events are being received with the correct types. Send a test transaction (devnet works well) and confirm:
- You receive an event whose
typeends in_V2(not_V1). - The payload contains both
triggeredByanddirection. - When two of your subscribed addresses are involved in the same transaction, you receive two events with different
triggeredByvalues and a sharedsignature.
- You receive an event whose