---
title: "Preview an audience"
method: GET
path: "/v1/projects/{project}/broadcasts/preview"
tags: ["Broadcasts"]
---

# Preview an audience

`GET /v1/projects/{project}/broadcasts/preview`

## Request

- Base URL: `https://api.subscriby.net`
- URL: `https://api.subscriby.net/v1/projects/{project}/broadcasts/preview`
- Auth: HTTP bearer

Sizes a broadcast without sending it. The dashboard shows this before the confirm button, and an API caller needs the same safety rail.

```bash
curl "https://api.subscriby.net/v1/projects/$PROJECT_ID/broadcasts/preview?audience=customer&plan_id=$PLAN_ID" \
  -H "Authorization: Bearer $SUBSCRIBY_TOKEN"
```

The preview accepts the same `audience`, `pass_window_id`, `plan_id` and `expiring_within_days` as the send, and applies them identically, segments, plan narrowing and recipient rules alike, so a preview and the send it precedes can never describe different audiences. The fields answer the same as the send's, minus `status`.

## Path parameters

- `project` string, uuid, required

## Query parameters

- `audience` string
- `pass_window_id` string, uuid
- `plan_id` string, uuid
- `expiring_within_days` integer

## Response `200`

The recipient count and ETA for the segment as described.

- object
  - `data` object, required: The response's payload.
    - `project_id` string, required: The project the broadcast would go out from.
    - `audience` string, required: The segment as verified.
    - `plan_id` string, nullable, required: The plan filter as verified; null when none was sent.
    - `expiring_within_days` integer, nullable, required: The horizon `expiring_soon` would use, after clamping; null for every other segment.
    - `recipient_estimate` integer, required: How many members the segment resolves to right now.
    - `estimated_seconds` integer, required: Roughly how long delivery would take at the platform's rate.

## Other responses

- `401`: `AUTHENTICATION_REQUIRED`: the request carries no bearer token, or one that is revoked, malformed, or minted for another environment (an `sbt_test_` token on production).
- `403`: `TOKEN_MISSING_ABILITY`: the token is valid but does not carry the ability this endpoint requires; `error.context.required_ability` names the one to grant. An endpoint that also checks who owns a row or which tier the account is on answers `FORBIDDEN`, `TEAM_TIER_REQUIRED` or `CONNECTOR_TIER_REQUIRED` with the same status, and says so in its own description.
- `404`: `RESOURCE_NOT_FOUND`: an id in the path names nothing the token can see. `TENANT_MISMATCH`: the project sits outside the token's `scope:project:` allow-list, or the token carries no team scope. Both answer 404 rather than 403 so that existence outside the token's scope cannot be inferred.
- `422`: `VALIDATION_FAILED`: with `error.context.reason` of `unknown_audience` (the context also lists `supported` values), `plan_filter_unsupported` or `unknown_plan`.
- `429`: `RATE_LIMITED`: the token has spent its 300 requests a minute or 10,000 an hour; `Retry-After` says when the next one is accepted.

---

[API](https://skmtc.dev/memberpass/apis/subscriby-rest-api.md) · [All operations](https://skmtc.dev/memberpass/apis/subscriby-rest-api/llms.txt) · [OpenAPI document](https://skmtc.dev/memberpass/apis/subscriby-rest-api/revisions/59c4df91d764?raw)