---
title: "Internal Queued Notifications"
method: GET
path: "/api/tradeworkz/internal/queued-notifications"
tags: ["TradeWorkz"]
---

# Internal Queued Notifications

`GET /api/tradeworkz/internal/queued-notifications`

## Request

- Base URL: `https://api.zerogex.io` (the document declares no server; this is the origin it was published from)
- URL: `https://api.zerogex.io/api/tradeworkz/internal/queued-notifications`
- Auth: HTTP bearer

Return queued email / webhook notification rows for the worker.

Rows are ordered by ``sent_at`` (which for a queued row is the
``NOW()`` at insert time — effectively FIFO). The worker pulls
``limit`` at a time so a burst of hundreds of exits doesn't stall
delivery of newer ones.

A queued row records that the follower *wanted* this channel at the
moment the event fanned out. Opt-in is re-checked here at delivery
time: a row is only handed to the worker if the recipient still
follows the bot with that channel enabled. This is the authoritative
guard behind unfollow / channel-off — it suppresses even backlog that
queued before the follower opted out (including rows orphaned by an
unfollow that removed the follower entirely), so "I unfollowed but the
emails keep coming" cannot happen regardless of how a row was queued.

## Query parameters

- `limit` integer
- `channel` string, nullable

## Response `200`

Successful Response

- object

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/zerogex/apis/zerogex-api.md) · [All operations](https://skmtc.dev/zerogex/apis/zerogex-api/llms.txt) · [OpenAPI document](https://skmtc.dev/zerogex/apis/zerogex-api/revisions/753b26bf0592?raw)