# Tools

Every tool BLU offers AI assistants — what it reads, the permission it needs, its inputs and the API endpoint behind it.

Each data tool reads exactly what one [API endpoint](https://docs.blu.luxe/reference/) returns, with the same permission and the same rules — the same code answers both, so for the same window your assistant and the API give the same numbers. Two differences are deliberate. In the tools, a date on its own as the **end** of a window means that whole day (`2026-10-19` = through 23:59:59 UTC), because that is what people mean; the API reads a bare date as the start of that day, so send it a full date-time to be exact. And a date that doesn't exist, such as `2026-09-31`, is refused by the tools with a message saying so, where the API rolls it over into the next month (`2026-09-31` becomes `2026-10-01`). The descriptions below are the words BLU gives the assistant, so they are written for it.

All tools only read — none of them can send a message to a fan or change anything in BLU. A tool your key has no permission for still appears in the assistant; using it returns a message naming the permission to turn on.

## Creator data

### `list_creators` — List creators

Permission: **Connected creators** (always granted). Same data as `GET /v1/creators`. Costs 1 unit a call.

List the creators currently connected to this agency: name, nickname, tags and `platformPid` (the OnlyFans performer id every other tool filters by). Use this first to resolve a creator's name to its platformPid.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `fields`: Only return these fields of each row (for example ["id","platformPid","name"]). Omit for every field.

### `list_all_creators` — List all creators, including removed ones

Permission: **All creators** (always granted). Same data as `GET /v1/all-creators`. Costs 1 unit a call.

List every creator under the agency whatever its connection status, including removed creators (`status`, `deletedTime`). Use this for questions about creators that were disconnected or removed. Needs a key with access to all creators. Known limitation: `deletedTime` is only populated for creators removed after status logging began — BLU hard-deletes creator rows, so it cannot be reconstructed for earlier removals. At most the 100 most recent removals are listed.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `fields`: Only return these fields of each row (for example ["id","platformPid","name"]). Omit for every field.

### `list_transactions` — List transactions

Permission: **Transactions** (opt-in). Same data as `GET /v1/transactions`. Costs 1 unit a call.

List individual revenue transactions (subscriptions, messages/PPV, tips, posts, streams) newest first, with amount, fee and net in CENTS, the transaction type and status, and a pseudonymous fanId. status is OnlyFans' own: done = completed, loading = still processing, undo = reversed (refunded or charged back), pending_return = a refund in progress; BLU's own earnings count every status except undo. Use this for "show recent payments" or to add up revenue over a short window. Window: startTime/endTime (default: the last 3 days; up to 366 days back). Get platformPid values from list_creators. Known limitation: `type` is derived from OnlyFans' own transaction description, which is localised. For a creator whose OnlyFans account is in a language BLU does not yet classify, `type` is `null` rather than a wrong bucket.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `endTime`: Window end, UTC, inclusive: a date (2026-10-19 = through the end of that day) or a date-time. Omit for up to now.
- `limit`: How many rows to return, 1-100 (default 50).
- `startTime`: Window start, UTC: a date (2026-10-01 = from 00:00 that day) or a date-time (2026-10-01T09:30:00Z). Omit both bounds for the last 72 hours. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["id","transactionId","platformPid"]). Omit for every field.

### `list_refunds` — List refunds and chargebacks

Permission: **Refunds** (opt-in). Same data as `GET /v1/refunds`. Costs 1 unit a call.

List refunds and chargebacks: when the payment was made, when it was disputed, the amount in CENTS and OnlyFans' reason code. Window: startTime/endTime (default: the last 3 days; up to 366 days back). Get platformPid values from list_creators. Known limitation: `transactionId` names the disputed payment (`transactionId` on /v1/transactions) only when BLU holds that payment: a chargeback for a payment made before BLU began syncing the creator has `null` there and in `refundReason`, which on production today is most of them. `paymentStatus` is the payment's status when BLU first recorded the chargeback.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `endTime`: Window end, UTC, inclusive: a date (2026-10-19 = through the end of that day) or a date-time. Omit for up to now.
- `limit`: How many rows to return, 1-100 (default 50).
- `startTime`: Window start, UTC: a date (2026-10-01 = from 00:00 that day) or a date-time (2026-10-01T09:30:00Z). Omit both bounds for the last 72 hours. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["id","transactionId","platformPid"]). Omit for every field.

### `list_links` — List tracking and free-trial links

Permission: **Tracking links, free trial links and profile promotions** (opt-in). Same data as `GET /v1/links`. Costs 1 unit a call.

List marketing links and their performance: clicks, subscribers, conversion, earnings (gross and net, CENTS), promotion cost, profit and ROI. `linkType` picks TRACKING (default) or TRIAL links; CAMPAIGN (profile promotions) is not synced yet and returns nothing. Use this for "which link brought the most subscribers". Known limitation: `linkType=CAMPAIGN` (profile promotions) returns an empty list: BLU does not yet sync promotion campaigns. `TRACKING` and `TRIAL` are complete. `profit`, `roi` and `cpc` are `null` until a promotion cost is entered for the link in BLU. A refunded or charged-back payment counts as 0, once OnlyFans has settled the refund — one still in progress is counted as earnings until it does, which is what the BLU app shows too. A refund recorded after the payment was already counted shows at the link's next recount: the sync runs every 2 hours, and a link is recounted when its subscriber count (for a trial, its claim count) changes, so a link nobody is clicking keeps its last figure. `source` and `tag` are labels your team sets in BLU, not referrer data — BLU does not see where a click came from.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `linkType`: Which links: TRACKING (default) or TRIAL. CAMPAIGN returns nothing yet.
- `status`: ACTIVE or DEACTIVATED links only.
- `fields`: Only return these fields of each row (for example ["id","platformPid","name"]). Omit for every field.

### `get_link_daily_stats` — Tracking-link clicks and subscribers per day

Permission: **Tracking link daily clicks and subscribers** (opt-in). Same data as `GET /v1/link-report/daily`. Costs 10 units a call.

One row per tracking link per day: clicks and subscribers gained that day, plus running totals. Days are the agency's report days. Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days per call, default today and the 3 days before). Up to 10 creators per call (creatorIds). Data starts on 2026-09-12. Get platformPid values from list_creators. Known limitation: OnlyFans keeps no history of a link's counters, so this series starts on 2026-09-12, the day BLU began writing them down: earlier days return no rows. A day's gain is `null` when the day before it was not recorded. Tracking links only — trial links are not recorded yet. There is no referrer or device breakdown: BLU does not receive one.

- `creatorIds`: Only these creators: up to 10 platformPid values (from list_creators). Omit for every creator this connection can see.
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["linkId","platformPid","date"]). Omit for every field.

### `list_link_fans` — List fans who came from a link

Permission: **Fans from tracking links, free trial links and profile promotions** (opt-in). Same data as `GET /v1/linkfans`. Costs 1 unit a call.

List the fans acquired through ONE marketing link and what each spent, by type (gross, in CENTS). Needs linkType and linkId (the link's `id` from list_links).

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `linkId` (required): The link's id, from list_links.
- `linkType` (required): Which kind of link linkId is: TRACKING or TRIAL. CAMPAIGN returns nothing yet.
- `fields`: Only return these fields of each row (for example ["id","fanId","fanName"]). Omit for every field.

### `list_automated_messages` — List automated messages

Permission: **Automated messages** (opt-in). Same data as `GET /v1/automated-messages`. Costs 1 unit a call.

List automated message campaigns: trigger, audience filters, the messages and price (CENTS), status and how many times each was sent. Purchases and revenue per campaign are not attributed yet (null). Get platformPid values from list_creators. Known limitation: Per-collection send, purchase and revenue counters are `null`, and so are campaign-level purchases and revenue: BLU records deliveries per recipient but does not yet attribute purchases to a campaign. `totalNumberOfTimeSent` is complete. `employeeId` is `null` when the campaign's author is no longer one of your employees.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `fields`: Only return these fields of each row (for example ["automatedMessageId","platformPid","employeeId"]). Omit for every field.

### `list_priority_mass_messages` — List priority mass messages

Permission: **Priority mass messages (PMM)** (opt-in). Same data as `GET /v1/priority-mass-messages`. Costs 1 unit a call.

List priority mass message campaigns: audience rules, price (CENTS), status, send time and how many were sent or failed. Purchases and revenue per campaign are not attributed yet (null). Get platformPid values from list_creators. Known limitation: Campaign-level purchases and revenue are `null`: BLU records deliveries per recipient but does not yet attribute purchases to a campaign. `totalNumberOfTimeSent` is complete. `employeeId` is `null` when the campaign's author is no longer one of your employees.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `fields`: Only return these fields of each row (for example ["platformPid","employeeId","status"]). Omit for every field.

### `list_sales_records` — List sales with employee attribution

Permission: **Sales records** (opt-in). Same data as `GET /v1/transaction-perf/details`. Costs 5 units a call.

List individual sales (paid PPV unlocks and tips) with who gets the credit: the attribution rule, the credited employee and the attributed amount (CENTS). Use this for "which chatter made this sale". Refunded or charged-back sales are left out unless includeReversed=true. Window: startTime/endTime (up to 31 days per call, default the last 3 days). Get platformPid values from list_creators. Known limitation: A sale is a paid PPV unlock or a tip: offers nobody bought and free unlocks are not returned. `campaignRef` groups the sales of one campaign or mass send — a PPV sent to a single fan has none. A campaign of another agency's on a creator you share is never named.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `endTime`: Window end, UTC, inclusive: a date (2026-10-19 = through the end of that day) or a date-time. Omit for up to now.
- `includeReversed`: true to include sales that were later refunded or charged back.
- `limit`: How many rows to return, 1-100 (default 50).
- `startTime`: Window start, UTC: a date (2026-10-01 = from 00:00 that day) or a date-time (2026-10-01T09:30:00Z). Omit both bounds for the last 72 hours. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["id","transactionId","platformPid"]). Omit for every field.

### `get_creator_chat_stats` — Chat activity per creator

Permission: **Messages sent statistics** (opt-in). Same data as `GET /v1/creator-report/chat-summary`. Costs 10 units a call.

Per creator, over the window: how fast fans got a reply (replyTime, milliseconds), messages sent through BLU, fans chatted, and PPVs sent and unlocked. Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days, default today and the 3 days before). Up to 10 creators per call. Get platformPid values from list_creators. Known limitation: `replyTime` is measured for fan messages from 2026-09-12: a window that starts earlier averages only the part after that date, and one entirely before it is `null`. It counts a reply by anyone on the creator side, including one typed in the OnlyFans Manager, which BLU sees but cannot attribute to an employee; a mass message is never a reply. Messages and fans chatted count what employees sent THROUGH BLU. Before 2026-09-12, `replyTime` carried the fan's latency to an employee, which is now `fanReplyTimeMs`.

- `creatorIds`: Only these creators: up to 10 platformPid values (from list_creators). Omit for every creator this connection can see.
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["platformPid","date","replyTime"]). Omit for every field.

### `get_fan_counts` — Active and expired fans per day

Permission: **Fans' status** (opt-in). Same data as `GET /v1/creator-report/fans/count`. Costs 10 units a call.

Per creator and day: activeFans (subscribed at the END of that day), expiredFans (lapsed DURING that day — a flow, never add it up as a total) and paidActiveFans. Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days, default today and the 3 days before). Up to 10 creators per call. Get platformPid values from list_creators. Known limitation: Days before the nightly rollup began are reconstructed from the current fan snapshot and are a LOWER BOUND: a fan who churned long enough ago that OnlyFans no longer returns them is absent, and a fan who left and re-subscribed keeps only their latest window. Recent days are measured, not reconstructed.

- `creatorIds`: Only these creators: up to 10 platformPid values (from list_creators). Omit for every creator this connection can see.
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["platformPid","date","activeFans"]). Omit for every field.

### `get_new_and_renewed_fans` — New and renewed subscriptions per day

Permission: **New and renewed fans** (opt-in). Same data as `GET /v1/creator-report/fans/subscriber-count`. Costs 10 units a call.

Per creator and day: new paid subscriptions and renewals, from the creator's own ledger. A free page reports 0 here even while it gains fans — use get_fan_counts for that. Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days, default today and the 3 days before). Up to 10 creators per call. Get platformPid values from list_creators.

- `creatorIds`: Only these creators: up to 10 platformPid values (from list_creators). Omit for every creator this connection can see.
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["platformPid","date","newSubscribers"]). Omit for every field.

### `get_fans_with_renew_on` — Fans with auto-renew on or off per day

Permission: **Fans with renew on** (opt-in). Same data as `GET /v1/creator-report/fans/renew-on`. Costs 10 units a call.

Per creator and day: active fans whose subscription will renew, and those who set it to expire. null before 2026-09-12. Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days, default today and the 3 days before). Up to 10 creators per call. Get platformPid values from list_creators. Known limitation: Returns `null` for days before 2026-09-12. Before then this endpoint counted a different OnlyFans flag, which read about 98% renewing where OnlyFans itself shows about 61%; those values are withdrawn rather than republished, and renewal state is point-in-time, so it cannot be reconstructed. Each day's value is one nightly snapshot of the fans active at that day's end, from each fan's own subscription as BLU last synced it: a fan who changed their mind since is counted as before, and for a creator with more than about 8,000 fans the older fans are not re-read daily. Never reported as 0 for a day that was not observed.

- `creatorIds`: Only these creators: up to 10 platformPid values (from list_creators). Omit for every creator this connection can see.
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["platformPid","date","fansWithRenewOn"]). Omit for every field.

### `get_fans_today` — Today's subscribers so far

Permission: **Fans today** (opt-in). Same data as `GET /v1/creator-report/fans/today`. Costs 1 unit a call.

Today so far, per creator: OnlyFans' own subscriber count, and the subscriptions bought and renewed since midnight in the agency's time zone. Use this for "how are we doing today". Get platformPid values from list_creators. Known limitation: `subscribersCount` is `null` until the creator's first sync after 2026-09-12. The subscription counts are `null` for a creator who is disconnected, because BLU is then not reading their ledger. They count PAID subscriptions, so a free page reports 0 new ones, as on /fans/subscriber-count.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `fields`: Only return these fields of each row (for example ["platformPid","date","utcOffset"]). Omit for every field.

### `get_subscription_length` — Average subscription length per day

Permission: **Fans' subscription length** (opt-in). Same data as `GET /v1/creator-report/fans/avg-subscription-length`. Costs 10 units a call.

Per creator and day: the average subscription length, in DAYS. Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days, default today and the 3 days before). Up to 10 creators per call. Get platformPid values from list_creators. Known limitation: Days before the nightly rollup began are reconstructed from the current fan snapshot and are a LOWER BOUND: a fan who churned long enough ago that OnlyFans no longer returns them is absent, and a fan who left and re-subscribed keeps only their latest window. Recent days are measured, not reconstructed.

- `creatorIds`: Only these creators: up to 10 platformPid values (from list_creators). Omit for every creator this connection can see.
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["platformPid","date","avgSubscriptionLength"]). Omit for every field.

### `get_profile_visitors` — Profile visitors per day

Permission: **Profile visitors** (opt-in). Same data as `GET /v1/creator-report/reach/profile-visitor-count`. Costs 10 units a call.

Per creator and day: profile visitors as OnlyFans counts them. Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days, default today and the 3 days before). Up to 10 creators per call. Get platformPid values from list_creators. Known limitation: The daily guest / logged-in split is `null`: BLU reads OnlyFans' daily visitor chart as one total. OnlyFans' split by visitor type is published per country, over the trailing year, on /v1/creator-report/reach/top-countries. The daily total itself is OnlyFans' own pre-aggregated daily bucket republished under the creator's local-day label — OnlyFans returns no intraday detail, so it cannot be re-bucketed, and where your report timezone differs from the account's the edges will not line up exactly.

- `creatorIds`: Only these creators: up to 10 platformPid values (from list_creators). Omit for every creator this connection can see.
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["platformPid","date","profileVisitors"]). Omit for every field.

### `get_profile_views_by_country` — Profile views by country

Permission: **Profile views by country** (opt-in). Same data as `GET /v1/creator-report/reach/top-countries`. Costs 1 unit a call.

Where each creator's profile views come from: OnlyFans' top ten countries plus "Others" over the trailing year, split into guests and logged-in users. These are views, not unique visitors, and nothing here locates an individual fan. Get platformPid values from list_creators. Known limitation: These are profile VIEWS, not unique visitors, exactly as OnlyFans reports them, re-read about hourly. OnlyFans gives no daily breakdown by country and no split by subscriber, so neither is offered. Nothing here identifies or locates a fan, and no endpoint in this API publishes a fan's location.

- `creatorId`: Only this creator: its platformPid (from list_creators).
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `fields`: Only return these fields of each row (for example ["platformPid","countryCode","countryName"]). Omit for every field.

### `list_creator_status_changes` — Creator connect / disconnect history

Permission: **Creator status log** (opt-in). Same data as `GET /v1/creator/status-change-log`. Costs 10 units a call.

Connect, disconnect, verification and removal events for creators, with who made the change (null = it was automatic, e.g. an expired session). Use this for "when did this creator disconnect". Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days, default today and the 3 days before). Up to 10 creators per call. Get platformPid values from list_creators. Known limitation: FORWARD-ONLY. A creator is hard-deleted along with everything attached to it, so there was nothing to reconstruct from: the log starts on the day BLU began recording it and no earlier history exists or can be produced. Removal events are only returned to a key scoped to ALL creators — a removed creator cannot be named in a `creatorIds` filter.

- `creatorIds`: Only these creators: up to 10 platformPid values (from list_creators). Omit for every creator this connection can see.
- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["id","creatorId","platformPid"]). Omit for every field.

## Employee data

### `list_employees` — List employees

Permission: **Employees** (always granted). Same data as `GET /v1/employees`. Costs 1 unit a call.

List the agency's employees (chatters and managers): id, name, status (deactivated ones are included) and when they were added. Use this to turn an employeeId from another tool into a name. Known limitation: `deletedTime` is always `null`: BLU hard-deletes employee records, so a removed employee is absent rather than tombstoned. Deactivated employees are returned with a DEACTIVATED status.

- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `employeeIds`: Only these employees: up to 10 employeeId values (from list_employees). Omit for everyone.
- `limit`: How many rows to return, 1-100 (default 50).
- `fields`: Only return these fields of each row (for example ["employeeId","employeeName","status"]). Omit for every field.

### `list_employee_creators` — Creators assigned to an employee

Permission: **Assigned creators** (always granted). Same data as `GET /v1/employees/assigned-creators`. Costs 1 unit a call.

List the creators one employee is assigned to. Needs employeeId (from list_employees).

- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `employeeId` (required): The employee: an employeeId from list_employees.
- `limit`: How many rows to return, 1-100 (default 50).
- `fields`: Only return these fields of each row (for example ["employeeId","creatorId","platformPid"]). Omit for every field.

### `get_employee_sales_stats` — Sales per employee per day

Permission: **Sales statistics** (opt-in). Same data as `GET /v1/employee-report/employee-sales-summary`. Costs 10 units a call.

Sales credited to each employee, per creator and day (the agency's report days): total sales, PPV and tips, in CENTS. Refunded and charged-back sales are excluded. Use this for "who was our best chatter last week". Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days, default today and the 3 days before). Up to 10 employeeIds per call; omit for everyone. Known limitation: A row exists for each employee, creator and day with any activity through BLU; `date` is a day in your agency's report timezone, and today's rows fill in through the day. `salesAmount` includes tips, and `ppvSalesAmount` is `salesAmount` minus `tipsSalesAmount`. The split by the channel a sale came through (direct message, priority mass, mass message) is not available yet.

- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `employeeIds`: Only these employees: up to 10 employeeId values (from list_employees). Omit for everyone.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["employeeId","date","platformPid"]). Omit for every field.

### `get_employee_chat_stats` — Chat activity per employee per day

Permission: **Chatting statistics** (opt-in). Same data as `GET /v1/employee-report/employee-chat-summary`. Costs 10 units a call.

Per employee, creator and day: messages and PPVs sent through BLU, PPVs unlocked, fans chatted, characters typed and how fast the employee replied to fans (milliseconds; from 2026-09-12). Window: reportStartTime/reportEndTime (YYYY-MM-DD; up to 31 days, default today and the 3 days before). Up to 10 employeeIds per call; omit for everyone. Known limitation: Messages count what employees sent THROUGH BLU: a message typed in the OnlyFans Manager tab is not seen, and neither is a reply sent that way. Response times are measured from 2026-09-12 — earlier days are `null` — as the time from a fan's message to the employee's first reply through BLU; a mass message is never a reply. `responseTimeBasedOnClockedHours` counts only fan messages that arrived while the employee was clocked in; percentiles are `null` below 5 replies. `responseTimeBasedOnScheduledHours` is `null`: replies are not yet measured against the shift schedule. `goldenRatio` is `null`: BLU has no source for it.

- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `employeeIds`: Only these employees: up to 10 employeeId values (from list_employees). Omit for everyone.
- `limit`: How many rows to return, 1-100 (default 50).
- `reportEndTime`: Last day of the report, YYYY-MM-DD, inclusive. Defaults to today.
- `reportStartTime`: First day of the report, YYYY-MM-DD (the agency's own days). Omit both for today and the 3 days before. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["employeeId","date","platformPid"]). Omit for every field.

## Organization data

### `get_monthly_billing` — BLU billing per month

Permission: **Invoice** (opt-in). Same data as `GET /v1/invoice-data/monthly-billing`. Costs 1 unit a call.

The agency's BLU bill per month: subscription charges, deductions, total, balance due, paid and pending (CENTS). This is what the agency pays BLU, not creator earnings. Window: startTime/endTime (default the last 3 days — pass the months you want). Known limitation: BLU bills from a credit ledger rather than issuing invoices, so `discount` and `igic` are always 0 and `invoiceId` is a derived, stable identifier rather than a document number.

- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `endTime`: Window end, UTC, inclusive: a date (2026-10-19 = through the end of that day) or a date-time. Omit for up to now.
- `limit`: How many rows to return, 1-100 (default 50).
- `startTime`: Window start, UTC: a date (2026-10-01 = from 00:00 that day) or a date-time (2026-10-01T09:30:00Z). Omit both bounds for the last 72 hours. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["billingId","invoiceId","billingPeriod"]). Omit for every field.

### `list_reassigned_sales` — Manually reassigned sales

Permission: **Reassigned sales log** (opt-in). Same data as `GET /v1/transaction-perf/manual-assignment/details`. Costs 5 units a call.

Sales whose credit was moved by hand from one employee to another: who moved it, from whom, to whom and when. Window: startTime/endTime (up to 31 days per call, default the last 3 days).

- `cursor`: The cursor from the previous call, to get the next page. Keep every other argument the same.
- `endTime`: Window end, UTC, inclusive: a date (2026-10-19 = through the end of that day) or a date-time. Omit for up to now.
- `limit`: How many rows to return, 1-100 (default 50).
- `startTime`: Window start, UTC: a date (2026-10-01 = from 00:00 that day) or a date-time (2026-10-01T09:30:00Z). Omit both bounds for the last 72 hours. At most 31 days per call. History goes back 366 days.
- `fields`: Only return these fields of each row (for example ["id","transactionId","transactionPerfId"]). Omit for every field.

## This connection

### `get_connection_info` — What this connection can read

No permission needed. Costs 1 unit a call.

Describe this BLU connection: the agency, the API key it uses, which creators and employees it covers, which kinds of data it may read (and which it may not), whether fans' names are included, its limits and the agency's report time zone. Call this first, and whenever a tool says something is not allowed.


## Not offered as a tool

- [Platform ranking](https://docs.blu.luxe/reference/v1/creator-report/rank/) (`GET /v1/creator-report/rank`): BLU does not capture OnlyFans' performance rank yet, so this endpoint returns null for every day. It becomes a tool when it carries data.

## What BLU tells the assistant

> BLU gives read-only access to one agency's BLU data: creators, fans, transactions, sales, chat and employee performance, links, mass messages and billing. Nothing can be changed. Money is integer cents (1230 = $12.30). Report days are the agency's own days; timestamps are UTC. null means BLU does not know — never treat it as 0. Call get_connection_info first to see what this connection can read. Creators are identified by platformPid (from list_creators); pass it as creatorId or creatorIds. Windowed tools default to a short recent window (the last 72 hours, or today and the 3 days before for daily reports), so pass explicit dates for anything longer. Lists are paginated: when hasMore is true, call again with the returned cursor and the same filters. Use `fields` to fetch only the columns you need when reading many rows. If a tool says the key lacks a permission, tell the user which one: the agency owner turns it on in BLU, under API keys → Edit.