Skip to main content
Pacifica can tell you when something happens on your account, for example when an order fills or a deposit completes. It delivers each notification on one or more channels: Notifications are off by default. To get a notification, turn on its channel in the master preference and for its notification type. See Preferences.

Notification types

Each notification has a notification_type. You set preferences for these types: Orders that an order strategy places also send order notifications. Send test notification sends the test type. You can’t set preferences for test. The API schema also lists account, trading, risk, price_alert, and announcement. Pacifica doesn’t send these types now, and you can’t set preferences for them. Strategy updates A strategy_update notification has an outcome in its data: Pacifica doesn’t send a notification when a strategy starts, pauses, or resumes, or when you cancel it.

Notification data

Each notification has a title, a body, and a data object. The title and body are English text for display. Use data to route a tap or click in your app. data always contains notification_type and kind. Both are set to the notification type. The other fields depend on the type. Decimal values are strings. IDs are strings. Orders (order_filled, order_partially_filled, order_canceled, tp_sl_triggered)
FieldTypeDescription
”order_id”stringOrder ID
”symbol”stringMarket symbol
”base_symbol”stringSame as “symbol"
"side”string”buy” or “sell"
"order_type”string”limit"
"market"
"stop limit"
"stop market"
"take profit"
"stop loss"
"price”decimal stringOrder price
”initial_amount”decimal stringorder_partially_filled only. Order amount
”filled_amount”decimal stringorder_partially_filled and order_filled only. Amount filled
”last_filled_price”decimal stringorder_filled only. Price of the last fill
”cancel_reason”stringorder_canceled only:
“canceled"
"force_canceled"
"expired"
"stop_price”decimal stringtp_sl_triggered only. Trigger price. Omitted when the order has no stop price
”trigger_kind”stringtp_sl_triggered only. “take_profit” or “stop_loss”
Liquidations (liquidation)
FieldTypeDescription
”history_id”stringTrade history ID
”order_id”string or nullOrder ID of the liquidation
”symbol”stringMarket symbol
”base_symbol”stringSame as “symbol"
"position_side”string”long” or “short"
"amount”decimal stringAmount liquidated
”price”decimal stringLiquidation price
”entry_price”decimal stringEntry price of the position
”pnl”decimal stringRealized PnL
”cause”string”market_liquidation"
"backstop_liquidation"
"insolvency_liquidation”
Deposits and withdrawals (deposit_success, withdraw_success)
FieldTypeDescription
”history_id”stringdeposit_success only. Deposit history ID
”signature”stringdeposit_success only. Deposit transaction signature
”withdraw_id”stringwithdraw_success only. Withdrawal ID
”tx_hash”stringwithdraw_success only. Withdrawal transaction hash
”asset”string”USDC”, or the spot asset
”symbol”stringSpot deposits and withdrawals only. Spot asset symbol
”amount”decimal stringAmount
Strategy updates (strategy_update)
FieldTypeDescription
”strategy_id”UUIDStrategy ID
”type”stringStrategy type, for example “twap"
"symbol”stringMarket symbol that the strategy trades
”base_symbol”stringSame as “symbol"
"lifecycle”stringThe strategy’s lifecycle after the change
”outcome”stringWhat happened. See Strategy updates above
”terminal_reason”string or nullWhy the strategy ended, for example “insufficient_balance”. Show your own label for this code

Preferences

An account has a master preference and a preference for each notification type. Each preference is a set of channels.
  • Pacifica uses a channel only when the channel is on in the master preference and in the type’s preference.
  • All channels start off. A missing preference counts as off.
  • The master preference doesn’t change the type preferences. You can turn a channel off in the master preference to pause it, and turn it on again later.
  • Pacifica picks the channels when it creates a notification. A later preference change doesn’t change notifications that already exist.
  • Turning on a type doesn’t backfill notifications for older events.
  • The test type uses only the master preference.
For example, to get order fills on the mobile app and in the history, turn on mobile_push and in_app with Set notification master preference. Then turn on the same channels for order_filled with Set notification preference.

Mobile push (Expo)

  1. On the first install, generate at least 128 random bits. Encode them as a string, for example hexadecimal. Keep this installation key in the device’s secure storage.
  2. Get the Expo push token from the Expo SDK.
  3. Call Register Expo device with the token, the platform, and the installation key as device_id.
  4. Turn on mobile_push in the master preference and for the types that you want.
  5. When the user signs out, call Unregister Expo device.
Keep the installation key secret. Don’t use a hardware ID or a user ID. The key proves that a request comes from the installation that owns the token. The push data is the notification’s data object. Route a tap by data.notification_type.

Web Push

  1. Call Get Web Push config. If enabled is false, hide Web Push in your app. Otherwise, read vapid_public_key.
  2. Generate an installation_id of 32 to 64 characters from A-Z, a-z, 0-9, -, and _. Store it where the page and the service worker can both read it, for example IndexedDB.
  3. In the browser, call pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: vapid_public_key }).
  4. Call Register Web Push subscription with the subscription’s endpoint and keys.
  5. Turn on web_push in the master preference and for the types that you want.
  6. In the service worker, show each push with showNotification. Use notification_id as the tag.
  7. When the page loads, call Get Web Push subscription status. If state is expired or key_rotated, subscribe again and register again.
  8. When the user signs out or switches account, call Unregister Web Push subscription.
Each push carries this encrypted JSON payload:
notification_id is the id that Get notification history returns. Route a click by data.notification_type.

History and seen

  • Get notification history returns only notifications that Pacifica created with the in_app channel on. Push-only notifications aren’t in the history.
  • It returns the 100 newest notifications, newest first. It has no pagination.
  • unread_count counts all in-app notifications that aren’t seen. It can be more than 100.
  • Mark notifications seen marks the IDs that you send. There is no “mark all” call. Send the IDs that you show.
  • Seen state belongs to the account. All the account’s devices and browsers see the same state.

Delivery

  • Pacifica sends a push only in the first 15 minutes after it creates the notification. After that, it drops the push. The notification stays in the history if in_app was on.
  • Pacifica sends a mobile_push notification to every active Expo token on the account. It turns off a token when Expo reports that the device is no longer registered.
  • Pacifica sends a web_push notification to every active Web Push subscription on the account. It turns off a subscription when the push service reports that the subscription is gone.
  • A push service accepting a push doesn’t mean the device showed it.

Signing and limits

  • An account keeps up to 10 active Web Push subscriptions. When you register one more, Pacifica turns off the subscription that was registered longest ago.
  • An app installation has one active Expo token for each account. When you register a new token with the same device_id, Pacifica turns off the old token.
  • The account must exist. An account exists after its first deposit. Other accounts get status 403.
  • The standard rate limits apply.