> For the complete documentation index, see [llms.txt](https://docs.hub88.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hub88.io/hubconnect-supplier-zone/supplier-promotions/streamers-exclusions-management.md).
# Streamers Exclusions Management
**Streamer Exclusions** area in Supplier Zone lets you review and decide, directly in HubConnect, when an operator's streamer campaign should be excluded from billing.
An operator's streamer plays on promotional funding rather than real player money, so that Gross Gaming Revenue (GGR) shouldn't count against you, but nothing comes off your billing until you say so.
You see exactly which of your own users, products, and games a request covers before you approve or reject it, one at a time or in bulk. You never see the operator's own player IDs, only your Supplier User IDs.
You can access Streamer Exclusions from the **Promotions** section in the HubConnect Supplier Zone sidebar.
The Streamers page has two tables:
* **Requests** for operator requests waiting for your decision, or recently decided.
* **All Exclusions** for every exclusion currently on your products, organised by Supplier User ID.
***
## Requests
Each row is one operator request:
| Column | Description |
| ----------------------------- | --------------------------------------------------------------------------------------- |
| **Type** | **New** or **Extension.** See [New requests vs Extensions](#new-requests-vs-extensions) |
| **Request Brand** | The operator's Brand the request applies to |
| **Products** | The products covered |
| **Games** | The games covered |
| **Supplier User IDs** | The users, identified in your own system |
| **Stream URL** | The streamer's channel |
| **Start Date** / **End Date** | The dates the exclusion covers |
| **Currencies** | The currencies the operator has scoped this exclusion to |
{% hint style="info" %}
If a request only asks to extend an existing exclusion's end date, a yellow info icon appears next to the End Date so you can tell it apart from a new request at a glance.
.png?alt=media\&token=1d474618-863d-4ee7-a6f0-67d230297dbe)
{% endhint %}
Filter the table by Brand, product, games, or date range, or search for a specific user ID.
### Approving or rejecting a request
For each request, you can **Approve** or **Reject**. Both actions ask you to confirm before they're applied.
* **Approving** confirms the same terms and conditions the operator accepted when they submitted the request. Once approved, the exclusion is created. See [Effective dates](#effective-dates).
* **Rejecting** lets you add a reason, which the operator sees.
To handle several requests at once, tick the checkboxes for the rows you want and use the **Approve** or **Reject** button at the top of the table.
Approving or rejecting an Extension request works the same way, but only the end date is decided on. See [Extensions](#extensions) below for what changes and what stays the same.
### Effective dates
Once you approve, the exclusion applies from the date the operator originally requested — not the date you approve it.
{% hint style="info" %}
**Example.** An operator requests an exclusion starting 1 September. You approve it on 5 September. The exclusion still applies from 1 September, so GGR from the covered users between 1 and 5 September is excluded from your billing too.
{% endhint %}
### Currency scope
Every request is scoped to specific currencies as well as specific products, games, and users. You see which currencies the operator has selected before you approve — chosen from the currencies their Brand supports — and what you approve is what applies to billing. Play from the same Supplier User ID in any other currency isn't covered and stays billable as normal.
{% hint style="info" %}
**Example.** You approve an exclusion scoped to EUR. The same user later plays in USD. That USD play isn't covered by the exclusion — you bill it as normal.
{% endhint %}
This doesn't change any exclusion you've already approved before currency scope was introduced, those continue to apply exactly as agreed.
### Extensions
An exclusion has a start date and usually an end date. The operator can change the end date at any point while it's running:
* **Adding** an end date to an open-ended exclusion, or **shortening** an existing one, applies immediately on the operator's side. It doesn't need your approval, and the exclusion stays Active.
* **Extending** to a later end date requires your agreement because it increases what's excluded from your billing. It's logged as an **Extension** — a status on the existing exclusion, not a new one — and lands in your Requests queue for a decision.
**How it works on your side:**
* Extension requests appear in the Requests queue with the current end date and the requested new one, so you can see exactly what's changing.
* **Approve** applies the new end date. **Reject** keeps the current one. Either way the exclusion continues, only the end date is in question.
* If the operator cancels the request, or ends the exclusion entirely while it's pending, it's shown as **Cancelled by the operator** in the queue. It isn't silently removed, and it isn't shown as Rejected, since you never acted on it.
| Term | What it means |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **Extension** | The status of an exclusion while a later end date is awaiting your decision |
| **Cancelled by the operator** | The state of an extension request the operator withdrew, or that was voided because they ended the exclusion while it was pending |
| **Shorten** | An immediate end-date change on the operator's side that needs no approval from you |
***
## All Exclusions
This table shows every exclusion on your products, organised by your own Supplier User ID:
| Column | Description |
| ----------------------------- | --------------------------------------- |
| **Supplier User ID** | The user, identified in your own system |
| **Partner** | The operator |
| **Brand** | The operator's Brand |
| **Excluded Products** | The products covered |
| **Excluded Games** | The games covered |
| **Stream URL** | The streamer's channel |
| **Start Date** / **End Date** | The dates the exclusion covers |
| **Status** | **Active** or **Rejected** |
Filter by Brand, partner, product, games, status, or date range, or search for a specific user ID.
***
## Frequently Asked Questions
**Can I see the operator's player IDs?** No. You only see Supplier User IDs, Hub88 maps these to the operator's own player IDs behind the scenes.
**What happens if I reject a request?** Nothing is excluded from your billing, and no GGR is affected. If you gave a reason, the operator sees it.
**Does it matter whether I approve a request before or after its start date?** No, the exclusion always applies from the requested start date. If that date has already passed when you approve, GGR from the covered users since that date is excluded too. Speak to your Hub88 account contact if you need help reconciling this against an invoice already issued.
**Can I approve or reject several requests at once?** Yes. Tick the checkboxes for the rows you want in the Requests table and use the Approve or Reject button at the top of the table.
**Where do I see everything I've already approved?** In the All Exclusions table, further down the Streamers page, organised by Supplier User ID.
**What's the difference between approving a New request and an Extension?** A New request sets up a fresh exclusion. An Extension only changes an existing exclusion's end date, approve to apply the new date, reject to keep the current one. Either way, the exclusion itself isn't affected.
**What happens if the operator cancels an extension request, or ends the exclusion while one is pending?** It shows as Cancelled by the operator in the Requests queue rather than being removed or marked Rejected, you didn't act on it, so it isn't recorded as a decision you made.
**What currencies does an exclusion cover?** Only the currencies the operator selected when they requested it. Play from a covered user in any other currency isn't excluded and stays billable, even if that play happens under the same Supplier User ID.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.hub88.io/hubconnect-supplier-zone/supplier-promotions/streamers-exclusions-management.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
.png?alt=media&token=be86c281-aec0-4636-9852-10fcfd09e795)
.png?alt=media&token=e5ae9d9f-2d60-443b-bd70-945e2db1430a)
.png?alt=media&token=2e014789-189c-41b8-9255-0327111764ed)
