Notifications

Notifications are built from the same algorithm and DSL system as feeds. The Console notification product has two connected workflows:

• Ingestion: create and manage notification ingests so account-owned users, wallets, or destinations are available to algorithms.
• Delivery: create notification configs that attach deployed algorithms to webhook delivery, cooldowns, priority filters, and daily budgets.

Do not build new user notification flows against the legacy alpha notification API. Console notifications use deployed algorithms and Studio deploy/config flows.

How the Console product works

1. Ingest the account-owned users or wallets that should be eligible for notifications.
2. Build and save a notification algorithm that searches a notification index.
3. Use .inAppUsers(...) when the algorithm needs to restrict candidates to your ingested users or wallets.
4. Open Notifications in Console.
5. In Ingestion, verify the ingest exists and is active.
6. In Delivery, create a notification config, select one or more deployed algorithms, review the generated DSL, and set webhook delivery.
7. Test the config, then deploy it.

Ingestion

Ingestion is the data-prep side of notifications. It gives Embed an account-scoped set of users, wallets, or delivery identities that your notification algorithms can join against.

Use ingestion when:

• notifications should only target your app's users,
• wallet alerts need to map back to your users,
• the algorithm should use .inAppUsers("wallet_address") or another account-owned field,
• you need Console to track which notification data set a delivery config depends on.

Ingested records are not the notification message. They are the audience or account-owned context used by the algorithm.

Delivery

Delivery is the config side of notifications. A delivery config:

• selects deployed algorithms with .algos([...]),
• sends matched candidates to your webhook with .webhook(...),
• controls repeat delivery with .cooldown(...),
• limits delivery with .priorityFilter(...) and .dailyBudget(...).

Your webhook receives the notification payload and decides how to render it in your app, send push/email, or trigger another downstream action.

Working notification algorithm

import { StudioV1 } from "algo-dsl";

export default async function notificationAlgo({ apiKey }) {
  const mbd = new StudioV1({ apiKey });

  return mbd
    .search()
    .index("dex-notifications")
    .include()
    .inAppUsers("wallet_address")
    .notNull("user_id")
    .sortBy("timestamp", "desc")
    .size(50)
    .execute();
}

Working delivery config

import { notification } from "algo-dsl";

export default notification("wallet-alerts")
  .algos([125])
  .webhook("https://your-app.com/webhooks/embed-notifications", {
    authBearer: process.env.EMBED_WEBHOOK_TOKEN
  })
  .cooldown({ hours: 4, key: "user_id" })
  .priorityFilter("P0,P1")
  .dailyBudget(5000);

Current notification indices

Use the names exposed in the Console algo dropdown:

• dex-notifications
• hyperliquid-notifications
• polymarket-notifications
• kalshi-notifications

Webhook handling

Your webhook should authenticate the request, accept the payload quickly, and enqueue slow work.

app.post("/webhooks/embed-notifications", express.json(), async (req, res) => {
  if (req.header("authorization") !== `Bearer ${process.env.EMBED_WEBHOOK_TOKEN}`) {
    return res.sendStatus(401);
  }

  await queueNotification(req.body);
  res.sendStatus(200);
});