# Mentio changelog What changed in Mentio, newest first. RSS: https://docs.mentio.dev/changelog/rss.xml. Docs: https://docs.mentio.dev. ## October 22, 2026: Show a keyword's mentions in some languages or countries only New. A keyword can hide its mentions in other languages or from other countries, everywhere you read them. The country, language and company filters narrow one list, view or alert rule. Now a keyword can say it once. * **`display` on a keyword:** `{ languages: { only, excluded }, countries: { only, excluded } }`, on `POST /v1/keywords` and `PATCH /v1/keywords/{id}`, and on every keyword returned. Languages are the 20 ISO 639-1 codes the classifier names, countries the 60 ISO 3166-1 alpha-2 codes the filters take. A language or place the classifier recognises but does not name counts as outside an `only` list. * **Hidden everywhere you read:** a mention outside the lists stays out of `GET /v1/mentions`, the CSV and JSON exports, MCP `search_mentions`, instant alerts and digests. `includeHidden=true` on the list shows it. * **Still billed:** language and country are known only once the classifier has read a post, so a hidden mention is matched and billed like any other. * **Unknown is shown:** a post whose language or country nobody could tell always comes through, so "only the US" does not lose every LinkedIn post, whose profiles share no location. * **Older mentions follow:** the lists are read when mentions are read, so a change hides or brings back what the keyword already found. * **Dashboard:** "What you see" in a keyword's settings. **MCP:** `add_keyword` and `update_keyword` take `display`. **SDKs and CLI:** `display` on keywords, `includeHidden` on mentions. See [Show only some languages or countries](/guides/keywords#show-only-some-languages-or-countries). ## October 18, 2026: Filter mentions by country, and leave companies out New. Every new mention says where its author is and whether a company posted it, and every mention filter can use both. Two questions the feed could not answer yet: where is this person, and is it a person at all. * **`classification.country`:** where the author is, as a lowercase ISO 3166-1 alpha-2 code (`us`, `in`, `de`). The classifier reads the location on the author's profile when the platform gives one (X, GitHub), then clues in their bio and the post. It is a best guess, and `null` when nothing tells: LinkedIn shares no location, so a LinkedIn post is placed only when its text says where. * **`classification.organization`:** `true` when a company, brand or organization posted as itself rather than a person. A LinkedIn company page always is. Someone who works at a company, or promotes their own product, is still a person. * **Filters:** `countries` and `notCountries` on `GET /v1/mentions`, the exports, views, alert rules and `anyOf` groups. A post whose country is unknown never passes `countries` and always passes `notCountries`, so `notCountries=in` hides posts placed in India and keeps the ones nobody could place. `organization=false` keeps people only, `true` companies only. * **Analytics:** `GET /v1/analytics/breakdown?by=country`. * **CSV export:** two more columns, `country` and `organization`. * **Dashboard:** Country and Author type chips on Mentions and in views; "Leave out countries" and "Author" on alert rules. * **MCP:** `search_mentions` and the view and alert tools take the same fields. **SDKs and CLI:** `--countries`, `--notCountries`, `--organization`. Both are labels like `automated`: nothing is hidden until you filter, and every matched mention is billed as before. Mentions classified before today have no country and read as posted by a person. ## October 18, 2026: Several searches in one keyword New. A keyword takes required combinations, an OR of ANDs, so one keyword covers several searches. A keyword could require one list of words, any or all of them. Now it can require **combinations**: the post must contain every word of at least one, so one keyword covers what used to be one search per line. * **`matching.requiredGroups`** on [`POST /v1/keywords`](/api/keywords/create-keyword) and [`PATCH /v1/keywords/{id}`](/api/keywords/update-keyword): a list of word lists. `inreach` with `[["weather", "alert*"], ["tsunami"], ["flash flood"]]` keeps posts about inReach weather alerts, tsunamis or flash floods. Up to 50 combinations of up to 10 words; `[]` clears them. With `requiredTerms` set too, a post must pass both. * **Wildcards on required words, documented:** a `*` at either end of a required word works as on excluded words (`alert*` matches *alerts* and *alerting*); the matcher already honored it, the API reference and the MCP tools now say so. * **Never billed when dropped:** a post no combination accepts is never stored, classified or billed. On X and LinkedIn, combinations without wildcards can narrow the paid search too. * **Dashboard:** Required combinations in the keyword's Matching rules, one row per combination. * **MCP:** `add_keyword` and `update_keyword` take `matching.requiredGroups`. **SDKs and CLI:** the new field on keyword matching. A keyword that never sets it sees no change. See [Several searches in one keyword](/guides/keywords#several-searches-in-one-keyword), with a table for moving a Syften filter file over. ## October 18, 2026: Workspace feeds, members-only forums and feed health New. Up to 500 RSS feeds every keyword reads, feeds behind a forum login, and an event when a feed stops working. Following many forums no longer means pasting each one into every keyword. * **Workspace feeds:** `/v1/feeds` holds up to 500 RSS or Atom feeds, and **every keyword** of the workspace reads them. `POST /v1/feeds/import` connects up to 100 in one call, each reported `added`, `already` or `failed` with an error code. The dashboard has a Feeds page to paste a list. A keyword opts out with `readsWorkspaceFeeds: false`; its own `feeds` (up to 20) work as before. * **Members-only forums:** a feed that answers a sign-in page is refused with `feed_login_required` instead of "no feed found". Give it your sign-in (`auth`: the Cookie header from your browser, or one header such as Discourse's `Api-Key`). It is stored encrypted, sent to that site alone, never shown again, and the feed is read for your workspace alone. * **Feed health:** every workspace feed shows `health` (`ok` or `failing`, the reason, since when). After 3 failed hourly reads a `feed.failing` event goes to the webhook, Slack, email and Telegram channels that subscribe to it, and `feed.recovered` when it reads again. Both are attention events (`GET /v1/attention`). * **MCP:** `list_feeds`, `add_feeds`, `update_feed` and `delete_feed`. **SDKs and CLI:** the `feeds:*` commands. Reading a feed is free; its matches bill like any mention. See [RSS feeds](/platforms/rss). ## October 13, 2026: Audience and segments by group Improved. The Audience and Segments pages have a Group selector, so a workspace with several keyword groups can look at one group's people and segments. The **Audience** and **Segments** pages now have a **Group** selector, next to the search. Pick a group to see only the people who mentioned that group's keywords, with that group's own tags, notes, mute, outreach log and segments. "All groups" is the whole workspace, as before. The choice stays in the page address, so it follows you between Audience and Segments and can be shared as a link. The selector only shows in a workspace with more than one group. See [People and segments by group](/guides/groups#people-and-segments-by-group). ## October 13, 2026: Mute and tags by keyword group Improved. A person can be muted for one keyword group, and a mention carries the tags its own group gave the author next to the workspace's. The two things a keyword group could not do with its people yet: mute them, and see its tags on their mentions. * **Mute per group:** `PATCH /v1/people/{id}?groupId=grp_...` now takes `muted`. It hides the person, and the accounts that group merged into them, from the mentions of **that group's keywords**: its feed, its alerts and its digests. Their mentions of another group's keywords stay, and the person reads `muted: false` there and in the workspace. It used to be a 400. * **A workspace mute is unchanged:** set without `groupId`, it hides the person everywhere, as before. * **Tags on mentions:** `author.tags` is the workspace's tags, then the tags the mention's own group gave that person, each once. * **Tag filters follow:** `tags` and `notTags` on `/v1/mentions`, in views and in alert rules look into the same list, so a rule with `groupIds` and `tags` fires on one customer's tagged people. One group's tags never show on, or filter, another group's mentions. * **`includeMuted=true`** on `/v1/mentions` shows what either mute hides. The `muted` filter of the people list reads the group's own value with `groupId`. * **MCP:** `update_person` takes `muted` with `groupId`. **SDKs and CLI:** no new parameters. A workspace that never passes `groupId` sees no change. See [People and segments by group](/guides/groups#people-and-segments-by-group). ## October 12, 2026: A weekly limit for auto recharge New. Auto recharge takes an optional weekly limit, the most your saved card is charged automatically in any 7 days. Auto recharge already charges at most once a day. You can now also set a **weekly limit** under Auto recharge on the Billing page: the most your saved card is charged automatically in any 7 days, before tax. If a top-up would pass it, nothing is charged and the billing page says when the next one can run, so a runaway keyword or a loop can never spend more than you agreed to. The wallet (`GET /v1/billing/wallet`, the SDKs and the CLI) reports the limit as `autoRecharge.weeklyLimitCents` and what counts against it over the last 7 days as `autoRecharge.spentThisWeekCents`. Changing it stays a signed-in owner's action, like the rest of auto recharge. ## October 12, 2026: People and segments by keyword group New. Every People and Segments endpoint takes groupId, so each keyword group has its own people, tags, notes, merges, outreach log and segments. People and segments can now be scoped to one **keyword group**, for a workspace that runs a customer per group. * **`?groupId=grp_...`** on every `/v1/people` and `/v1/segments` endpoint, reads and writes alike, the CSV export included. Without it, every call behaves as before. * **Who is listed:** only the people who mentioned that group's keywords, with `stats` counted over the group's mentions. A person the group never matched is a 404 there. * **A clean slate per group:** tags, notes, outreach owner and stage, merges, activities and segments are the group's own. Nothing crosses between groups, or between a group and the workspace, and two groups can each keep a segment called "VIPs". * **New on the segment:** `groupId`, the group it belongs to, or `null` for a workspace segment. A `segmentId` from another scope is a 404. * **Not yet:** a mute per group, and group tags on mentions. `muted` sent with `groupId` is a 400 and a mute is still set for the whole workspace; `author.tags` and the tag filters on `/v1/mentions` still read the workspace's tags. * **A misplaced scope is refused:** `group_id` or `groupIds` in the query, or `groupId` in the JSON body, is a 400 on these endpoints, never an answer for the whole workspace. The MCP tools refuse a misspelled one the same way. * **MCP:** the people, activity and segment tools take `groupId`. **SDKs and CLI:** the same parameter on the same operations. `groupId` is a filter your backend passes, not an access control: an API key still acts on the whole workspace. See [People and segments by group](/guides/groups#people-and-segments-by-group). ## October 9, 2026: Mention caps per day or week New. A keyword's mention cap can count per day or per week, not only per month, so spend has a ceiling and mentions keep coming every day. A mention cap can now count per **day** or per **week**, as well as per month. * **`cap: { "mentions": 50, "per": "day" }`** on `POST /v1/keywords` and `PATCH /v1/keywords/{id}`. `per` is `day` (from 00:00 UTC), `week` (from Monday 00:00 UTC) or `month`, the default, so every existing cap is unchanged. * **Why a daily cap:** a monthly cap on a busy term can be used up in a day and then wait for the 1st. A daily one keeps mentions coming every day while a keyword never costs more than 30 × the cap × $0.008 a month, plus its $5: the control to sell tracking at a fixed price per customer. * **New on the keyword:** `cap.per`, `cap.used` (counted in the current period) and `cap.resumesAt` (when a capped keyword matches again). * **Webhooks:** `keyword.capped` carries `cap.per`, and `keyword.resumed` has a new reason, `period_turned`, for a daily or weekly cap. The owner email is sent for monthly caps only. * **MCP:** `add_keyword` and `update_keyword` take `per`. **Dashboard:** the cap field has a day, week or month choice, and the keywords list shows the count for the period. See [Capping a keyword's mentions](/billing#capping-a-keywords-mentions). ## October 9, 2026: Add funds in one step Improved. Adding funds opens a small window with the amount, a few presets and the balance it leads to, then the checkout. The Billing page has an **Add funds** button on the balance. It opens a window where you type the amount (or pick $20, $50, $100, $250 or $500), see the balance it brings you to, and continue to the secure checkout. The minimum is still $20, and the amount can still change at checkout. ## October 8, 2026: GitHub repositories, with a rule for what you pay for New. A keyword tracked on GitHub now also hears about repositories naming it (a new one with traction, a star milestone, fast growth), and matching.repositories chooses which events become mentions. GitHub mentions were issues and pull requests. They now include **repositories** whose name, description or topics carry your keyword, as events: * **Traction.** A repository under 30 days old reached 10 stars. * **Star milestone.** A repository with 100 stars or more passed 100, 250, 500, 1,000, 2,000, 5,000 and so on. * **Fast growth.** It gained at least 100 stars and 20% of its stars in a week. * **New repository** (off by default). Every repository created, even with no stars: for a brand name, where each one is somebody building with your product. **`matching.repositories`** on a keyword chooses what becomes a mention: `events`, `minStars` and `minWeeklyStars`. It is applied before a mention is stored, so anything outside the rule is never billed. "Repositories about linkedin mcp with 200 stars or more, gaining 100 a week" is `{ "events": ["stars", "growth"], "minStars": 200, "minWeeklyStars": 100 }`. The keyword drawer has the same switches under GitHub repositories. A repository event is a mention with **`post.kind: "repository"`** (a third kind beside `post` and `comment`, and a value of the `kind` filter) and **`post.repository`**: `{ name, event, stars, weeklyStars }`. `post.title` says it as a sentence ("owner/name passed 2,000 stars"), the stars are also `post.engagement.likes`, and the owner is the author. Repositories are checked every 6 hours. Details in [GitHub](/platforms/github#repositories). ## October 8, 2026: Reddit: subreddit, flair, score and comment count on every post New. Reddit mentions carry their subreddit, flair, score and comment count, and you can filter, alert and group by subreddit. A Reddit post now says where it was written and how it is doing. * **New fields.** `post.subreddit` (without the `r/`), `post.flair`, and `post.engagement` with `likes` (the post's score) and `replies` (its comment count), as they stood when the post was found. Posts stored before today got their subreddit filled in; score and flair start now. * **Filter by subreddit.** `subreddits` and `notSubreddits` on `GET /v1/mentions`, the CSV and JSON exports, [views](/guides/views), `anyOf` groups and alert rules, so "tell me when r/SaaS talks about us" is one rule. `minLikes` and `minReplies` now work on Reddit: only posts with at least that score or that many comments. * **Which subreddits talk about you.** `GET /v1/analytics/breakdown?by=subreddit` ranks them; the dashboard shows the top ones on Analytics, and MCP's `get_analytics_breakdown` takes `by: "subreddit"`. * **In the dashboard**, a Reddit mention shows its subreddit (click it to read everything from there), its flair, its score and its comments, and the mentions list has a Subreddit filter. * **Fixed:** the comment thread of a Reddit post is read through the right endpoint, so threads no longer come back empty or through the paid fallback. ## October 8, 2026: Rename and duplicate keywords New. Change a keyword's term without starting over, and copy a keyword with all its settings to track a new term. * **Rename.** A keyword's term is now editable, in its settings or with `term` on [`PATCH /v1/keywords/{id}`](/api/keywords/update-keyword). It keeps its id, its settings and the mentions it already found; the new term is tracked from the moment you rename it, with no look-back and no extra charge. * **Duplicate.** The Duplicate button in a keyword's settings, [`POST /v1/keywords/{id}/duplicate`](/api/keywords/duplicate-keyword), the MCP tool `duplicate_keyword` or `mentio keywords:duplicate` creates a new keyword with the same platforms, context, matching rules, cap and comments setting under a term you choose. Review apps and feeds are copied only when you ask (`include`). The copy is a new keyword, billed as one, and its last 30 days come in at once. See [Choosing keywords](/guides/keywords#rename-or-duplicate-a-keyword). ## October 8, 2026: Subreddit rules per keyword New. A keyword can now keep its Reddit posts to a list of subreddits, or out of some, without touching the workspace's other keywords. A keyword's `matching` now takes `subreddits`: `only` keeps that keyword's Reddit posts to the subreddits you list, `excluded` drops the ones you name. Until now the two lists existed for the whole workspace only (the filters in Settings), so excluding a subreddit for one brand excluded it for every keyword. Both levels apply together: a Reddit post must pass the workspace filters and the keyword's own rules. A post a rule rejects is never stored or billed. Rules apply to new mentions. In the dashboard the two fields are in the keyword's settings, under Matching rules. On the API: `PATCH /v1/keywords/{id}` with `{ "matching": { "subreddits": { "excluded": ["chennai"] } } }`; each list is replaced when sent and kept when omitted. The MCP tools `add_keyword` and `update_keyword` take the same field. ## October 8, 2026: A tidier Settings page Improved. Settings is now a narrow column of small cards, with the noise filters on their own tab. Settings has four tabs: Company, Filters, Billing and Integrations. The noise filters, which used to sit under the company profile, have their own tab. Each tab is a narrow column of small cards (Company, Relevance and Social accounts; Words and authors, Reddit and GitHub), and each card saves on its own, so an edit in one never touches another. The company description now stops at 1,000 characters, the most the profile accepts; a longer one used to fail on save. ## October 8, 2026: Usage by group, keyword, platform and date Improved. The usage breakdown takes a custom date window and filters by keyword, group and platform, and the Usage page has a filter bar, weekly and monthly views and a cumulative line. `GET /v1/usage/breakdown` takes `from` and `to` (any window of UTC days, up to 366) and narrows every number with `keywordIds`, `groupIds` and `platforms`, alone or together. A keyword's daily charge belongs to no platform, so a platform filter counts mentions and comments only; the response says `filtered: true` whenever a filter applied. The MCP tool `get_usage_breakdown` takes the same. On the dashboard, the Usage page has a filter bar (range, custom dates, product, group, keyword, platform), Daily, Weekly and Monthly views with a Cumulative switch, and the costs in colour: keywords, mentions and comments each keep one colour across the chart, the charge lines and their trends. Click a keyword, a group or a platform in the tables below to filter the page to it. ## October 8, 2026: RSS feeds: forums behind a browser check, and a save that names every bad feed Fixed. Feeds behind a "checking your browser" page now connect, and a list with a bad feed says which ones fail instead of losing the rest. * **Forums behind a browser check.** Some forums answer every automated request, RSS included, with a "checking your browser" page first. Mentio now passes a check that works without JavaScript the way a browser without JavaScript does, as its own feed reader and only where the site's `robots.txt` allows it. Feeds such as XenForo forums' `/index.rss` connect and are read every hour. A check that needs JavaScript or a CAPTCHA still cannot be read, and says so. * **Saving a list with a bad feed.** Saving checked the feeds only until the first one failed, named only that one, and saved nothing. Every feed is now checked and the error names each one that fails and why. In the dashboard, each feed is checked as you add it: you see its title, or the reason it cannot be read, before you save. ## October 7, 2026: Comments on mentions New. Read the conversation under your mentions, and filter posts from comments. Switch comments on for a keyword and Mentio reads the thread under each of its relevant mentions on Reddit, YouTube, Hacker News, Bluesky, GitHub, Stack Overflow and DEV, from 30 minutes after the post and for as long as conversations last there: a day on Reddit, Hacker News and Bluesky, a week on GitHub, Stack Overflow and DEV, a month on YouTube. Comments that say nothing ("lol", "+1") are skipped and never billed. * `GET /v1/mentions/{id}/comments` lists a mention's thread, newest first, whether or not each comment names your keyword, with a light sentiment and intent read and `mentionId` when a comment is itself one of your mentions. MCP: `list_mention_comments`. * `comments: { enabled, maxPerPost }` on `POST` and `PATCH /v1/keywords`, off by default, 20 comments per mention unless you say otherwise (up to 100). * Every mention now carries `post.kind` (`post` or `comment`), `parentMentionId` and `stats.comments`; `kind=post|comment` filters the list, the export, views and the MCP search (`isReply` still works). * Comments are $0.008 each, once per workspace, on their own line of the bill: `debit_comments` in the ledger, `billableComments` and `commentCents` in the usage breakdown and in `keywords.stats.cost`. * **Billing moves for replies, at the same price.** From today, a matched reply (X and Bluesky replies, Hacker News comments, Stack Overflow answers) bills on the comments line instead of the mentions line, whether or not the keyword has comments on, and once per workspace even when two keywords match it. If you read `billableMentions` or `mentionCents`, add `billableComments` and `commentCents` for the whole variable bill. Replies billed before today stay on the mentions line. * The monthly cap (`cap.mentions`) now counts the comments delivered under a keyword's mentions too, so it bounds the whole variable bill. See the [comments guide](/guides/comments). ## October 7, 2026: Keywords read RSS and Atom feeds New. A keyword can now read up to 20 RSS or Atom feeds, so forums, communities and blogs that no platform search reaches become mentions. A keyword now takes `feeds`: up to 20 RSS or Atom feeds, or the addresses of the sites that publish them (a forum, a community, a blog). Mentio finds each site's feed when the keyword is saved, reads it every hour, and makes a mention of every post that holds the term, with the keyword's matching rules. A newly connected feed brings its newest 10 matching posts of the last 30 days. Mentions arrive as `platform: rss`, priced like any other. On the API, `feeds` is on `POST /v1/keywords` and `PATCH /v1/keywords/{id}` (and the MCP tools `add_keyword` and `update_keyword`); a keyword shows its feeds with their title. See [RSS feeds](/platforms/rss). ## October 7, 2026: TikTok videos found by what they say, and keyword.matchedIn New. Mentio now reads the subtitles of TikTok videos, so a video that says your keyword out loud is a mention, and every mention says whether it matched in the text or in the speech. * **Speech.** When a TikTok video has subtitles (the creator's, or TikTok's automatic ones), Mentio reads them, so a video that only *says* your keyword is found too. The transcript is part of the mention's `post.text`, after a `🎙` mark, so the API, the CLI, the MCP tools and the dashboard show it with no new call. * **`keyword.matchedIn`** on every mention: `speech` when the keyword is only in what the video says, `text` otherwise (the post, the caption, the hashtags, the review). Filter or label on it in your own code, or ask your agent for "TikTok mentions said in the video". Speech applies to videos found from 6 October 2026; earlier videos are not re-read. ## October 7, 2026: Cleaner keyword drawers, review pages and analytics filters Improved. Adding and editing a keyword is quicker to read, matching rules can be set from the start, and review pages show the app's real name and icon. * **Adding a keyword** fits on one screen: the term, its kind as three buttons, and platforms as a grid of toggles. Reviews, comments and RSS feeds are rows you open when you need them, and the price sits next to the Add button. * **Matching rules from the start.** Required words, excluded words, exact phrase and case sensitive can be set while adding a keyword, so a noisy term is clean from its first mention. Comments can be switched on there too, with the number per mention. * **A keyword's settings** use the same layout, with health first, then platforms, then rules. Health suggestions show what they remove (noise, relevant posts, money) at a glance, and the per-platform breakdown is a table. * **Review pages** show the app's real name and icon (App Store) or the company's (Trustpilot). App store countries are chips with flags: type a code and press Enter or a comma. * **Groups** list first, with a "New group" row to add one. * **Analytics** filters platforms with one dropdown instead of a row of icons, and the Reviews page shows ratings as stars and colors each page by its platform. ## October 7, 2026: Cross-posts show as one mention Improved. When someone posts the same thing in several places, you now see it once, with links to every copy, and get one alert instead of several. * **One card per post.** When the same author posts the same text again for the same keyword within three days (an announcement pasted into five subreddits, a launch post sent twice), the first post is shown once with "Also posted in r/..." linking to the others. Only the first sends an instant alert and appears in the digest. * **`duplicates` and `duplicateOf`** on every mention: the original lists its copies (id, platform, url, publishedAt), and a copy names its original. `GET /v1/mentions`, the JSON export and the MCP `search_mentions` tool list originals only; `includeDuplicates=true` lists every copy too. The CSV export keeps a row per mention with a new `duplicate_of` column. * **Billing is unchanged.** Each copy is a real post: it is matched and billed like any mention, takes the first post's classification, and counts toward the keyword's monthly cap and the digest's totals. Applies to posts matched from today; earlier copies stay listed on their own. ## October 7, 2026: Required and excluded words take plurals Improved. A keyword's required and excluded words now match their plural and singular forms, so requiring "alert" also accepts "alerts". A keyword's required and excluded words now match the way the keyword itself does: the last word in its plural or singular form (`alert` also matches *alerts*, `agency` also matches *agencies*), and the term written as one word (`social media` also matches *#socialmedia*). Domains, symbols and wildcard entries keep matching exactly as written. Rules apply to new mentions. ## October 6, 2026: A guide to choosing keywords, and a warning for sentences Improved. A new guide explains how a keyword matches and how to pick terms that find posts, and the dashboard warns when a keyword reads like a sentence. A keyword finds posts that contain its words. Written as a sentence ("looking for a corporate fundraising agency"), it finds almost nothing, because nobody writes that sentence word for word. * **[Choosing keywords](/guides/keywords)** explains how a keyword matches (the phrase, or its words close together), how to pick terms people actually write, how to narrow a broad one, and what you pay for. * **The dashboard says it where you type.** Adding a keyword shows how it will match and links to the guide. A term that reads like a sentence gets a warning, and one that opens with "looking for" or "how to" gets a shorter term to try, one click to use it. Onboarding warns the same way. ## October 6, 2026: Hashtags match their keyword, and long keywords find related posts Improved. A hashtag that spells your keyword now counts as the keyword, and a keyword of three words or more also finds posts holding all of its words but a generic one. Platforms like TikTok, Instagram and LinkedIn write keywords as hashtags and answer a search with posts about it, not only posts that spell it. Two matching rules catch more of those. * **Hashtags.** A hashtag or handle that spells the whole keyword counts as the keyword: `social listening` matches `#SocialListening`, and `fundraising for nonprofits` matches `#fundraisingnonprofits` (a keyword in quotes too). It bills like any other match. The same goes for excluded and required terms. * **All words but a generic one.** A keyword of three meaningful words or more also matches a post holding all of them but one generic word (*api*, *tool*, *app*, *software*, *platform*, *agency*, *best*, *free* and the like), close together: `social listening api` matches "Social listening software usually costs thousands". Every other word is still required, so `notion project management` never matches without *notion*. Like close words, such a post is kept and billed only when the classifier scores it relevant, and only on posts found by searching for your keyword. Wrap a keyword in double quotes, or set `matching.exactPhrase`, to match the phrase alone. See [Choosing keywords](/guides/keywords). ## October 6, 2026: Instagram look-backs cover the last week Improved. A new keyword's Instagram look-back now reads the last 7 days, and Instagram is checked twice a day. * **The last 7 days.** When you create a keyword or turn on Instagram for one, its look-back now reads the newest posts of the last 7 days (it was 10). Every post it reads can now be kept, so a look-back brings more of them to your feed. * **Caption search after half a day.** A new keyword's first search of Instagram captions runs after about 12 hours and reaches back to when the keyword was created. Hashtag posts arrive from the start. * **Twice a day.** Instagram is checked every 12 hours, and each check reads what was posted since the last one (up to 200 hashtag posts a check). ## October 6, 2026: Keywords match their words close together, billed only when relevant Improved. A multi-word keyword now also finds posts that hold its words a few apart, in any order or form. Those posts are kept and billed only when the classifier scores them relevant. Until today a keyword of two words or more matched only posts holding it word for word. "Fundraising for nonprofit organization" missed "fundraising efforts. For nonprofit organizations", and a keyword written as a sentence often found nothing at all. * **Close words.** A multi-word keyword also matches a post that holds all its meaningful words within a few words of each other, in any order. Plurals count, and so do joined, hyphenated and spaced spellings (`nonprofit`, `non-profit`, `non profit`). Filler words like *for* and *the* are not required. Close words apply to the posts found by searching for your keyword; Bluesky's live stream and the Hacker News, DEV and news feeds match the phrase only. * **Billed only when relevant.** A post found this way is kept, alerted and billed only when the classifier scores it relevant. The rest is dropped and costs nothing. A post that holds the phrase itself bills as before. * **`keyword.matchedAs`** on every mention says how it matched: `phrase` or `close_words`. * **The exact phrase alone.** Wrap the term in double quotes (`"social media api"`) when you create a keyword, or set `matching.exactPhrase: true` on [`POST`](/api/keywords/create-keyword) or [`PATCH /v1/keywords/{id}`](/api/keywords/update-keyword). Single words and case-sensitive keywords match as written. [How it works](/how-it-works#matching-rules) has the full rule. The SDKs, the CLI and the MCP tools (`add_keyword`, `update_keyword`) take the new field. ## October 4, 2026: A clearer Telegram alert Improved. Instant alerts in Telegram read at a glance and open with a button. Instant alerts in Telegram have a new layout: * One header with what the mention is and the keyword it matched. * One line with the author, their handle, the platform, their followers and who they are replying to. * The post first, as a quote, then Mentio's note. * A verdict line: relevance, sentiment and tags. * **Open on X** (or the platform) and **Open in Mentio** as buttons under the message, in private chats, groups and channels. ## October 4, 2026: Author privacy, removal requests and no emails over MCP Improved. The MCP people tools no longer return a person's email address, anyone can ask for their posts to be removed at mentio.dev/privacy/remove, and a removal erases their posts from every workspace. Mentio stores public posts and the public facts about the people who wrote them. This release makes how we handle that data clearer and gives those people a way out. * **No email addresses over MCP.** `list_people`, `get_person`, `update_person`, `merge_people`, `log_activity` and every other people tool now return `profile.email` as `null`. The REST API (`GET /v1/people/{id}`) and the dashboard still show it where the person published it on their public profile. * **Removal requests.** Anyone can ask for their accounts to be removed at [mentio.dev/privacy/remove](https://mentio.dev/privacy/remove/) or by writing to [support@mentio.dev](mailto:support@mentio.dev). They get a receipt by email, and we complete every request within 30 days. * **Erasure.** A completed removal deletes the person's posts from every workspace (with the notes, tags and outreach activity attached to them), empties their profile, and stops Mentio from storing their future posts. Billing history is kept: a mention you were charged for stays on your ledger and usage totals. * **Privacy policy.** The [privacy policy](https://mentio.dev/privacy) now says what we store about post authors, on what basis (legitimate interests, GDPR Art. 6(1)(f)), for how long, and who controls the notes a workspace adds. ## October 2, 2026: Hourly digests New. An alert rule can now send one digest every hour, and nothing for an hour with nothing new. Alert rules take a new mode, `hourly`. Every UTC hour the rule sends one digest of the hour before (matched from 09:00 to 10:00, sent at 10:05 so the hour's last mentions are scored) to its Slack, Telegram and webhook channels: the same two lists as the daily digest, headed "Last hour", with the counts against the previous hour. An hour with nothing to show (no mention at or over the rule's relevance floor) sends nothing. ```bash curl -X POST "$MENTIONS_API_URL/v1/alerts" \ -H "Authorization: Bearer $MENTIONS_API_KEY" -H "Content-Type: application/json" \ -d '{ "name": "Hourly heat", "mode": "hourly", "filter": { "sentiments": ["negative"] }, "channelIds": ["dest_…"] }' ``` * An hourly rule takes no `schedule`. A time of day and a time zone are ignored; a `weekday` is refused, since a rule cannot be hourly and weekly at once. * Hourly digests are not sent by email: up to 24 a day per rule would bury an inbox. A rule with an email channel answers `400 hourly_email_unsupported`; email keeps instant alerts and daily or weekly digests. * A delivery that fails for a reason that can pass is retried until 45 minutes past the hour (10:45 for the 09:00 hour), then that hour is dropped rather than sent late next to the following one. Its mentions stay in the feed. * `POST /v1/alerts/{id}/run` on an hourly rule sends the last hour now. A scheduled run given up for lateness reports `skipped: "expired"`. * In the dashboard, pick **Hourly digest** under Alerts. The MCP tools (`create_alert`, `update_alert`), the SDKs and the CLI take `mode: "hourly"` too. * Migrating from Octolens: a destination with `frequency` `hourly` or `hourlyAtTopOfHour` and `deliveryMode: batch` is a Mentio hourly rule ([guide](/migrate/octolens)). ## October 2, 2026: Needs attention, with spike alerts New. Mentio now watches every keyword and channel once an hour and tells you about mention spikes, negative spikes, noisy keywords and failing channels, in the dashboard, over the API and on Slack, email, Telegram or a webhook. Some things should not wait for the daily digest. Mentio now looks for them once an hour and opens an attention item for each. * **Four kinds.** `mention.spike`: a keyword got at least 10 fresh mentions in the last hour, 4 times its usual hourly rate and well outside its normal spread. `sentiment.negative_spike`: 5 or more of its relevant mentions in 24 hours were negative, a share at least 2.5 times its usual one. `keyword.noisy`: its health reads noisy (every match bills, relevant or not). `channel.failing`: a channel's last 5 sends failed. Thresholds set on two weeks of production data so a real burst opens an item and a busy hour does not. * **Once per episode.** An item opens when its condition starts and resolves on its own when it is gone; one open item per keyword or channel and kind, and none again for 24 hours after one resolved. Dismiss it and it stays away while the condition lasts. * **API.** `GET /v1/attention` (open by default, `status=resolved|dismissed|all`, `kind`) and `POST /v1/attention/{id}/dismiss`. In the SDKs, the CLI (`attention:list`, `attention:dismiss`) and the MCP tools `list_attention` and `dismiss_attention`. * **Sent once, where you choose.** Each opening is an account event of the same name. Webhooks subscribe with `events` as before; Slack, email and Telegram channels can now subscribe to these four as well and get one short message with the keyword and a link. Email keeps the instant alert caps and only reaches confirmed addresses. * **Dashboard.** A Needs attention card above the mentions with a Dismiss on each item, and an Attention alerts switch on every Slack, email and Telegram channel under Alerts. Never billed. Details in [Needs attention](/guides/attention). ## October 2, 2026: Excluded authors match the same way everywhere, and long searches work Fixed. An excluded author now hides exactly the posts an alert would skip, in the mentions list, views, exports and the alert preview. Searches longer than about 50 bytes no longer fail. **Excluded authors.** An entry in `excludeAuthors` (on `GET /v1/mentions`, the export, a view or an alert rule) now matches an author exactly as alert delivery always did: it must equal the author's display name, their profile link, or the handle in that link (the `?id=` of a Hacker News link, the name after `/in/`, `/company/`, `/user/` or `/profile/`, else the last part of the link), ignoring case. Before, the mentions list also matched a plain word anywhere inside a profile link, so excluding `user` hid every Reddit and Hacker News author while alerts still sent their posts. A name with accented capitals (`ÉMILE`) now matches its lowercase form in the list too, as it did in alerts. If you exclude plain words, the list, views and the `alertId` preview may now show a few more posts: exactly the ones your alerts were already sending. **Long searches.** A text search (`q`) longer than about 50 bytes, which is 25 accented characters, failed with an error because of a limit in the database. Searches now work up to the full 200 characters on mentions, exports, views, `anyOf` groups and the MCP search, and so do long people searches, handles and link hosts. What a search matches is unchanged: case-insensitive for plain letters, literal for `%` and `_`. ## October 1, 2026: Keyword health and suggestions New. Each keyword now says whether it earns what it costs, what its noise is made of, and which change would cut it, measured on its own posts and ready to apply with one PATCH. Every match bills, relevant or not, so a keyword whose term mostly means something else spends its budget on noise. Now the API says which keywords those are and what to change. * `GET /v1/keywords/{id}/health` reads a trailing window (`range=7d|30d|90d`, 30 days by default) and answers a `status` (healthy, noisy, quiet, capped, paused, new) with `reasons` in plain words, the numbers by platform and by week, what the keyword cost, the words and authors over-represented in its noise, and `suggestions`. * Each suggestion (drop a platform, exclude terms, exclude authors, require terms, rewrite the context) carries a `patch` you send to `PATCH /v1/keywords/{id}` as is, and an `effect` measured by running the matcher's own rules over the window's posts: the noise and relevant matches it would have removed, and the cents it would have saved. * After you change a keyword's rules, platforms or context, the status and the suggestions judge only the matches since the change (`stats.judgedSince`), so a keyword you just tightened is not called noisy on the noise you removed; the numbers keep the whole window. * `ai=true` adds a context rewritten by a language model, cached a day; 20 model calls an hour per workspace. * Every keyword in `GET /v1/keywords` carries `stats.health`, the same status over the last 14 days or since the last change (the endpoint defaults to 30, so the two can differ), for a badge without one call per keyword. * Read only and never billed; 30 reads a minute per workspace. In the SDKs, the CLI (`mentio keywords:health `) and as the MCP tool `get_keyword_health`. The dashboard badges a noisy or quiet keyword and a Health section in the keyword drawer, with an Apply button on each suggestion. Details in [Keyword health](/guides/keyword-health). ## October 1, 2026: OR in mention filters with anyOf New. Keep a mention when any one of several groups of conditions holds, on the mentions list, the exports, saved views, alert rules and MCP. Every mention filter narrowed the others: "Reddit and negative" was easy, "negative on Reddit, or anyone about to buy" was two requests. `anyOf` says it in one. * **Groups of conditions.** `anyOf` takes 1 to 10 groups. Each group holds the conditions of a saved view (platforms, sentiments, intents, keyword kinds, the `not` lists and the rest), all of them ANDed, and a mention passes when at least one group holds. Every other filter still applies: the whole filter is (other filters) AND (group 1 OR group 2 ...). * **Everywhere filters go.** `GET /v1/mentions` and both exports take it as URL-encoded JSON: `anyOf=[{"platforms":["reddit"],"sentiments":["negative"]},{"intents":["buy_intent"]}]`. A saved view's `filter`, an alert rule's `filter` and the MCP `search_mentions` tool take the same groups as JSON. Instant alerts, digests and the `alertId` preview read a rule's groups the same way. * **Never wider by accident.** An empty group, an empty `anyOf`, a nested `anyOf` or a misspelled field is a `400`. * **A new error, `filter_too_complex`.** One query takes at most 100 values, so a filter whose lists and groups together would need more (a view or alert rule applied on top included) answers `400` before anything runs, and a view or rule whose groups could never fit is refused when it is saved. * **The dashboard keeps them.** The view and alert rule editors show a rule's groups and keep them when you edit the rest; building groups is for the API and MCP for now. The [Octolens-compatible API](/migrate/octolens) uses it too: filters that mix AND and OR groups across fields, and tag lists mixing intent tags with `own_brand_mention`, `competitor_mention` or `ai_generated`, now work instead of answering `501`, up to 10 alternatives once written out. See [OR across groups](/conventions#or-across-groups-anyof). ## October 1, 2026: Engagement filters, a JSON export, people by handle and four new tags Improved. Filter mentions by likes, replies or views, leave star ratings out, export the list as JSON, find a person by handle, and read a post's title and preview image. A set of smaller additions to the mentions and people APIs, most of them things Octolens users asked for when moving over. * **Engagement minimums.** `minLikes`, `minReposts`, `minReplies`, `minQuotes`, `minViews` and `minBookmarks` keep posts with at least that many, as the platform reported them when the post was found. A post without that count never passes. They work on `GET /v1/mentions`, the exports, saved views and alert rules. * **Leave star ratings out.** `notRatings` is the twin of `ratings`: `notRatings=5` hides the five star reviews and keeps every post that is not a review. Same places as `ratings`. * **JSON export.** `GET /v1/mentions/export.json` takes the list's filters and returns every matching mention in one response, each one the same object the list returns, up to 10,000, with `truncated` when the cap cut it. It shares the CSV export's limit of 6 exports a minute. * **Find a person by handle.** `GET /v1/people?handle=` takes a handle (`@jane`, `u/jane`) or a profile or post link and returns the person behind it, merged accounts included. Add `platform` to pick one platform. MCP `list_people` takes it too. * **Four new tags.** The classifier now also tags `testimonial` (a user vouching for the product from their own use), `industry_insight` (data, a trend or analysis about the field), `launch` (a product, feature or release announced) and `feedback` (a suggestion or request to improve it). Every tag filter takes them. * **Post title and image.** `post.title` is the post's own title where the platform has one (Hacker News, Reddit, GitHub, Stack Overflow, DEV, YouTube, news, titled reviews) and `post.imageUrl` its preview image when the platform sent one (YouTube, DEV, news, Bluesky). Both are null for posts found before today. The [Octolens-compatible API](/migrate/octolens) picks all of this up: X engagement thresholds, excluding star ratings and exporting one author now work instead of answering `501`, and mentions carry `title` and `imageUrl`. ## September 29, 2026: Onboarding sets rules for brand names that mean something else Improved. When your brand or a competitor shares its name with an everyday word, a person or a bigger company, setup proposes matching rules before your first mentions arrive. A brand called Baker, Profound or Linear shares its name with far more posts about something else. Until now, setup tracked the bare word, and the first mentions a new workspace saw (and paid for) were about bakeries and adjectives. * **Setup spots ambiguous names.** When the website analysis finds that your brand or a competitor has another common meaning, the keyword comes with rules: words a post must also contain (for a marketing agency: ads, marketing, agency...), words that only go with the other meaning (bakery, baking...), and a note for the relevance filter. * **You see them before anything is created**, as one line under the keyword, and can edit or remove them in a drawer. The 30-day look-back runs with them, so posts they reject are never stored or billed. * **Tags and links always count.** A post tagging your @handle or naming your domain passes the rules, and for an ambiguous brand the domain itself (withbaker for withbaker.com) is offered as a keyword. * **Distinctive names get no rules**, and matching is never made case-sensitive, so "tried baker for our ads" still counts. Rules can be changed at any time from the keyword's drawer on the Keywords page. ## September 28, 2026: An Octolens-compatible API New. Point Octolens code, the octolens CLI and integrations built on its API at https://api.mentio.dev/compat/octolens with a Mentio key, and they keep working. Mentio now answers Octolens' `/api/v2` endpoints at `https://api.mentio.dev/compat/octolens`, with Octolens' own request and response shapes and error codes. Moving is two changes: the base URL and the API key. ```bash export OCTOLENS_BASE_URL=https://api.mentio.dev/compat/octolens export OCTOLENS_API_KEY=mk_live_... octolens keywords list ``` * **Keywords, mentions, feeds, global filters, tags, feedback, analytics, the company profile, usage and members** work as on Octolens. A keyword created this way gets the same 30-day look-back as any Mentio keyword. * **A copy script** in the guide moves your keywords, feeds, global filters and company profile from Octolens in one run. * **What Mentio does not have** (agency workspaces, setup scans, AI helpers, on-demand search, suggestions, notifications) answers `501 FEATURE_DISABLED` instead of a wrong result. Guide: [Migrate from Octolens](/migrate/octolens). ## September 27, 2026: App Store and Google Play reviews New. A keyword can collect the reviews of the apps it names, your own or a competitor's, as mentions with their star rating, the app version and the developer's reply. Mentio now collects app store reviews. Name an app on a keyword, with its App Store or Google Play link, and every new review of that app becomes a mention of the keyword, whether or not the review says the app's name. * **Connect an app:** `reviewSources` on `POST /v1/keywords` and `PATCH /v1/keywords/{id}` (and the MCP `add_keyword` and `update_keyword` tools), a store link or a `platform` and `id`, with the storefronts to read (`countries`) and, on Google Play, the review `language`. * **Reviews only:** `platforms: []` now means the term is searched nowhere, for a keyword that only collects its apps' reviews (a competitor's app, say). A keyword with neither is refused. * **What comes with it:** a new `review` concern on the mention: `rating`, `ratingMax`, `title`, `version`, `country`, the developer's `response` and when it was written, and the `app`. * **Relevance and sentiment:** a review always counts as relevant, and its sentiment comes from the stars (4 and 5 positive, 3 neutral, 1 and 2 negative). The intent tags are still read from the text. * **Filter on the stars:** `ratings` on the mentions list, the export, views and alert rules; the CSV adds `rating` and `app_id`. * **Platforms:** `appstore` and `googleplay` are new values of `platform` on mentions, filters and analytics. A keyword's `platforms` list is still where its term is searched and never holds them. Reviews are collected once a day per app and storefront. Connecting an app brings its last 30 days at once (the newest 100 reviews per storefront), free and without instant alerts; after that each new review bills like any mention. Guide: [App store reviews](/platforms/reviews). ## September 27, 2026: Reviews report and a Reviews page New. One report on your reviews across every page your keywords collect, as an API call, an MCP tool and a new Reviews page in the dashboard. `GET /v1/analytics/reviews` covers a window of your App Store, Google Play, Trustpilot and Google reviews. It gives the average stars, how the stars split, how many reviews got a reply, how many 1 and 2 star reviews are still open, and the tags on the unhappy ones. Each review page gets the same numbers plus its stars over time. With `compare=true` you also get the period before. * **MCP:** `get_reviews_report`. **CLI:** `mentio analytics:reviews`. * **Dashboard:** a new **Reviews** page in the sidebar. Click a star count or a tag to open those reviews in Mentions. * **Mentions:** a new **Rating** filter chip, the `ratings` filter the API already had. * **Alerts:** a **Bad reviews alert** button. It sets up an instant rule for 1 and 2 star reviews. The webhooks page also gets a `review.negative` preset. * **Fixed:** Google Play reviewers who share a display name are no longer merged into one person in your audience. Guide: [Report on reviews](/platforms/reviews#report-on-reviews). ## September 27, 2026: Trustpilot and Google reviews New. A keyword can now collect the reviews of a company's Trustpilot page and of a place's Google reviews, the same way it collects App Store and Google Play reviews. Two more review platforms join the App Store and Google Play: `trustpilot` and `googlemaps`. Add the page to a keyword's `reviewSources` and every new review becomes a mention of the keyword, with its stars, whether or not it names you. * **Trustpilot:** paste the company's page (`https://www.trustpilot.com/review/notion.so`, any country's site) or give `{ "platform": "trustpilot", "id": "notion.so" }`. Mentions carry the title, the verified badge (`review.verified`, new), the reviewer's country and the company's reply. * **Google reviews:** paste the place's Google Maps link, the short `maps.app.goo.gl` link from Share, or a Place ID. Mentions carry the owner's reply and how many people found the review helpful; a rating with no words still arrives. * **Same rules as the app stores:** checked once a day, relevance set by the keyword's kind and sentiment by the stars, the `ratings` filter, the last 30 days free when you connect a page (once per workspace), then $0.008 a review. Neither takes `countries`: one page for everyone. Guide: [How reviews work](/platforms/reviews). ## September 27, 2026: Instagram reads back ten days Improved. A keyword that turns Instagram on now gets its last ten days of posts at once, instead of a month. When a keyword starts listening on Instagram, Mentio now brings in its newest posts of the last ten days, instead of the last month. Every other platform still reads back 30 days. An Instagram keyword that keeps finding nothing is now read less often, down to about once a day, and goes back to every six hours as soon as it finds a post. An active keyword is unchanged: its hashtag every six hours, its captions up to twice a day. ## September 27, 2026: The welcome credit goes to mentions about you Improved. Until a workspace adds funds, each keyword collects up to 200 mentions a month, and a keyword that is mostly noise is paused instead of spending the credit. A new workspace starts with $5.80 of credit. Until its first top-up, two guards keep that credit for mentions that are about you. * **200 mentions a keyword a month.** Every keyword carries the limit as its cap, marked `cap.welcome: true`. At the limit it waits for the first of the month and is not charged its daily keyword fee meanwhile. The first top-up removes the limit and resumes the keyword at once. A cap of your own under 200 stays yours; a higher one is kept in `cap.own` and applies from your first top-up. * **The noise brake.** A keyword with at least 20 scored matches of which fewer than 30% are relevant is paused. It reads `pausedForNoise: true` and lists under `status=noisy`, and every owner gets an email. Add a required or excluded term, or change its platforms, and it starts again. You can also unmute it as it is. Once a workspace has added funds, neither applies. Guide: [The welcome credit](/billing#the-welcome-credit). ## September 26, 2026: Instagram is the twelfth platform New. Keywords now watch Instagram posts and reels that name them in the caption, tagged or not, with the author, likes and comments. Mentio now tracks Instagram. Your existing keywords keep the platforms they had and do not start on Instagram by themselves: turn it on per keyword, in the keyword drawer or by adding `instagram` to its `platforms`, and it reads back the last month at once. Keywords you create from now on track every platform, Instagram included, unless you choose otherwise. * **What is found:** posts and reels whose caption names your keyword, whether or not they use its hashtag, and, for a one-word keyword, the new posts under its hashtag (up to 200 a read on a busy tag). A reel that only says your name out loud is found when public search has transcribed it. * **How often:** the hashtag every six hours; captions twice a day, since a post reaches search a few hours after it is published. A new keyword also gets its last month of Instagram at once. * **What comes with it:** the author and their profile link in the Audience, and the likes and comments of the post when it was found, under `post.engagement`. Follower counts are not collected. * **In the API:** `instagram` is a new value of `platform` everywhere it is accepted or returned. Muting takes a profile link (`instagram.com/name`); a post link does not name its author on Instagram. Pricing is unchanged: an Instagram mention bills like any other. ## September 26, 2026: TikTok is the eleventh platform New. Keywords now watch TikTok, new videos whose caption or hashtags name them, with the creator's followers and each video's views, likes, comments, shares and saves. Mentio now tracks TikTok. Your existing keywords keep the platforms they had and do not start on TikTok by themselves: turn it on per keyword, in the keyword drawer or by adding `tiktok` to its `platforms`, and it reads back the last month at once. Keywords you create from now on track every platform, TikTok included, unless you choose otherwise. * **What is found:** new videos whose caption or hashtags contain your keyword. A video that only says your name out loud is not found, because TikTok search does not reach speech. * **How often:** every three hours, over the last day of videos. A new keyword also gets its last month of TikTok at once, like the other platforms. * **What comes with it:** the creator, with their followers, in the Audience; and the views, likes, comments, shares and saves of the video when it was found, under `post.engagement`. * **In the API:** `tiktok` is a new value of `platform` everywhere it is accepted or returned: the mentions list and export, analytics, alert rules, views and keyword platforms. Muting takes a profile or video link (`tiktok.com/@name`). Pricing is unchanged: a TikTok mention bills like any other. ## September 26, 2026: A company description per keyword group Improved. A group can carry its own company description; the classifier reads it in place of the workspace profile for that group's keywords, so one workspace can serve several businesses and have each judged as itself. The classifier judges every mention against "the company", which until now was always the workspace's company profile. A workspace tracking keywords for several businesses had every one of them judged as if it belonged to the workspace's own company, and a keyword's `context` (a short instruction) could not stand in for a description. A [keyword group](/guides/groups) now takes `context`: who the business is, what it sells, for whom, what is not it, up to the length of the workspace profile. The classifier reads it in place of the whole workspace profile (guidelines and competitor list included) for every keyword in the group, and a verdict is no longer reused across groups with different descriptions. Null keeps the workspace profile, so nothing changes for a workspace that does not set it. * `context` on `POST /v1/groups` and `PATCH /v1/groups/{id}` (null clears); every group carries it. * MCP `create_group` and `update_group` take it; the SDKs, the CLI and the OpenClaw skill are regenerated. * The Groups drawer on the Keywords page has the field. New mentions are judged with the description at once; old ones are not rescored. ## September 24, 2026: A monthly mention cap per keyword New. Give a keyword a monthly ceiling on matched mentions. At the cap it stops matching until the month turns or you raise it, so a keyword's variable cost has a fixed bound. A keyword costs $5 a month whatever happens, but its mentions bill one by one and nobody knows how many a month brings. If you resell tracking at a fixed price, or just want a month's spend bounded, that variable needs a ceiling. Now it has one. * `cap: { "mentions": 500 }` on `POST /v1/keywords` and `PATCH /v1/keywords/{id}` (`null` removes it), in the SDKs, the CLI (`--cap`) and the MCP tools `add_keyword` and `update_keyword`. * The count is the new `stats.thisMonth`: matches recorded in the current calendar month (UTC), relevant or not, the look-back a new keyword gets included, because every match bills. * At the cap the keyword stops matching: `pausedForCap` is true, it lists under `status=capped`, `GET /v1/usage` counts it under `keywords.capped`, and every owner gets one email. It resumes on the first of the next month, or the moment a `PATCH` raises the cap above the count or removes it. * It is not a mute: the keyword keeps its place and its daily keyword charge. Set `muted: true` to stop that too. On the **Keywords** page, the add form and the drawer have a **Monthly mention cap** field (set it when you add the keyword and it bounds the first look-back too), each capped keyword shows its month's count against the cap, and a keyword at its cap carries an **At monthly cap** badge. Details in [Billing](/billing#capping-a-keywords-mentions). ## September 24, 2026: Cost per keyword, from the API New. A public usage breakdown by keyword, platform or day over a trailing window or a calendar month, and this month's cost on every keyword. Margins per customer no longer need to be computed from the price list. If you resell tracking, or just want to know which keyword is eating the balance, you could read this month's match count per keyword but not what each keyword cost: the $5 slot charged by the day plus its mentions at $0.008. Now the API says it. * `GET /v1/usage/breakdown` is public: what the workspace consumed and was charged, in USD cents at list price, grouped by one dimension per call. `by=keyword` (the default) is the row a margin is computed from: days charged, mentions billed, each priced, and `totalCents`; a keyword deleted during the window keeps its row with `keyword.removed`. `by=platform` and `by=day` group the same numbers the other ways, and every call carries the window's `totals`, including what the wallet actually debited. * `range=7d|30d|90d` reads a trailing window ending today; `month=YYYY-MM` reads one calendar month, from its first day to its last or to today for the running one: the shape a bill or a margin per customer is reconciled against. * Rows are paged (`limit` up to 500, `offset`, `total`), and a workspace may read the breakdown 30 times a minute. * Every keyword now carries `stats.cost` for the running month (`keywordDays`, `keywordCents`, `billableMentions`, `mentionCents`, `totalCents`), the same words as the breakdown's rows, so `GET /v1/keywords` is one call for the cost of every keyword today, and it equals the keyword's row in the breakdown of the same month. * In the SDKs and the CLI (`mentio usage:breakdown --by keyword --month 2026-09`), and as the MCP tool `get_usage_breakdown`. Details in [Billing](/billing#cost-per-keyword). ## September 24, 2026: Keyword groups New. Group keywords by customer, campaign or product. A term may be tracked once per group, every mention and keyword names its group, alert rules and the mentions list filter by it, and the usage breakdown bills per group. A workspace can now group its keywords. A group is whatever you count by, a customer, a campaign, a product, and every keyword belongs to one. A term is unique per group rather than per workspace, so two groups may track the same word as two keywords with their own rules, context, cap and bill. Every workspace has a default group, created with it, where a keyword lands when no group is named; it can be renamed, never deleted. * `GET`, `POST /v1/groups`, `GET`, `PATCH`, `DELETE /v1/groups/{id}`. A group has a `name` and an optional `externalId` (your own id, unique per workspace, found again with `?externalId=`). Deleting a group deletes its keywords the way `DELETE /v1/keywords/{id}` does. * `groupId` on `POST /v1/keywords` puts a keyword in a group, on `PATCH /v1/keywords/{id}` moves it, on `GET /v1/keywords` lists one group's. Every keyword carries `group`. * Every mention carries `keyword.group`, in the API, the webhook payload and the CSV export (`group`, `group_external_id`). `groupIds` (and `notGroupIds`) narrows `GET /v1/mentions`, the export and a view's filter; an alert rule's filter takes `groupIds` too, so one rule can serve one customer whatever its keywords are on the day. * `GET /v1/usage/breakdown?by=group` is the bill per group. Keyword-days count under the group the keyword was in on the day they were charged. * MCP: `list_groups`, `get_group`, `create_group`, `update_group`, `delete_group`; `groupId` on `add_keyword` and `update_keyword`; `groupIds` on `search_mentions`. The SDKs, the CLI (`groups:*`) and the OpenClaw skill are regenerated. The dashboard shows groups once a second one exists: a group dropdown beside the search and a group badge on Keywords, a group picker when adding or editing a keyword, and a By group table on Usage. Everything is in [Keyword groups](/guides/groups). ## September 24, 2026: The wallet in the API New. The balance, the ledger, a top-up checkout and the receipts are now public API, with CLI commands and an MCP ledger tool. Until now the wallet was a dashboard thing: a program could read `GET /v1/usage` and nothing else. An integrator running its own billing on top of Mentio needs the rest, so the billing routes the dashboard uses are now part of the API: * `GET /v1/billing/wallet`: the balance in full, the top-up bounds and the auto-recharge settings. * `GET /v1/billing/ledger`: every movement of the balance, newest first, cursor paged. * `POST /v1/billing/top-ups`: a hosted checkout URL with the amount prefilled. Nothing is charged by the call; the balance is credited when the payment lands, and paused tracking resumes at once. `successUrl` is optional now. * `GET /v1/billing/invoices` and `GET /v1/billing/invoices/{id}/url`: the receipts. Auto recharge stays behind a login on purpose: it charges a saved card with nobody present, so only a signed-in owner can change it, from the billing page or an OAuth sign-in, never with an API key. The CLI gains `billing:wallet`, `billing:ledger`, `billing:top-up`, `billing:invoices` and `billing:invoice-url`; the MCP server gains `list_ledger`. Details in [Billing](/billing#the-wallet-through-the-api). ## September 24, 2026: Webhooks for keyword and wallet state changes New. A webhook channel can now subscribe to keyword.capped, keyword.paused_for_balance, keyword.resumed, wallet.low, wallet.paused and wallet.resumed, so nobody has to poll every keyword to learn that one stopped. A keyword at its monthly cap, or every keyword paused because the balance ran out, used to reach you by email only; a system that acts on it had to poll each keyword. Now the change itself is a webhook. * Six account events, with no rule behind them: `keyword.capped`, `keyword.paused_for_balance`, `keyword.resumed` (with a `reason`: `balance_restored`, `cap_raised`, `cap_removed` or `month_turned`), `wallet.low` (once per credit, at 20% of the last one), `wallet.paused` and `wallet.resumed`. * A webhook channel subscribes by name: `events` on `POST /v1/channels` and `PATCH /v1/channels/{id}` (the whole set, replaced; empty unsubscribes), read back as `config.events`. The same endpoint keeps receiving what its rules send. * The payload is the usual envelope with `alert: null` and a `data` shape per event: the keyword (`id`, `term`, `kind`), the cap and count, the wallet as the event saw it, and the instants. Signed exactly like every other delivery. * Recorded the moment the transition happens, delivered within about a minute, at least once, with the retries mention deliveries get. The channel's delivery log lists them as `kind: "event"`, and every delivery row now carries its `event` name. * On the dashboard, a webhook's form has an **Account** group of events next to the mention and digest presets. The emails to owners go out as before. Details in [Account events](/webhooks/account-events). ## September 24, 2026: Alert rules can deliver every match Improved. An alert rule's minRelevance is now its relevance floor. Absent it sends relevant mentions only, as before; set to 0 it delivers every scored match, so a webhook can show everything that was billed. Every matched mention bills, relevant or not, but a webhook only ever received the relevant ones. A reseller showing its customers what they paid for could not, and neither could anyone who wanted to check the classifier's noise. * `minRelevance` on an alert rule's filter is now the rule's relevance floor. Absent, the rule sends mentions scored 40 and up, exactly as before. Set it lower, down to `0`, and the rule also receives the matches the classifier scored as noise, with `data.relevant` `false` and the score in `data.classification.relevance`. * Webhook, Slack and Telegram channels get what the rule asks for; email channels keep the 40 line, so a busy keyword's noise never becomes instant mail. * `GET /v1/mentions?alertId=` and the digest's lists follow the same floor; digest counts still include every match a rule's other conditions accept. * On the **Alerts** page the relevance slider now reads 40 by default, and 0 means every match. Nothing changes for a rule that never set `minRelevance`. Details in [Webhooks](/webhooks/mention-events). ## September 24, 2026: Required terms now narrow the search on LinkedIn and X Improved. When every keyword on a term has required terms, the LinkedIn and X searches ask for them too, so a keyword with rules is not fetching posts it will never keep. A keyword's required terms used to be applied only after a post was fetched. On LinkedIn and X, where every post returned is paid for, a keyword like "ai enablement" that requires "hiring", "remote" or "apply" was fetching hundreds of posts to keep a handful. The search now asks for the required terms too: `"ai enablement" AND (hiring OR remote OR apply)` on LinkedIn, and the same with hashtags on X. Nothing changes in what is kept: every rule is still checked on every post afterwards. Two limits, both on purpose: * The search stays as it was when another keyword tracks the same term without required terms, when a required term is not a plain word (a domain like `beel.es`, a hyphenated word), or when the rules are too long for the platform's query. * A required term that a post carries only inside a link or an @handle can now be missed on these two platforms, because the platforms' search does not look there. ## September 24, 2026: Webhook signatures carry a timestamp Improved. Every webhook request now carries X-Mentions-Timestamp and X-Mentions-Signature-V2, signed over the timestamp and the body, so a captured delivery cannot be replayed. The old header stays. A webhook signature over the body alone proves who sent a request, not when. Someone holding a captured delivery could send it again a week later and it would still verify. Every request now carries two more headers: * `X-Mentions-Timestamp`: Unix seconds when the request was built. * `X-Mentions-Signature-V2`: `v2=` plus the hex HMAC-SHA256 of `.`, keyed with your channel secret. Verify V2 and reject a timestamp more than a few minutes from your clock; retries carry a fresh timestamp and signature with the same delivery `id`. `X-Mentions-Signature`, the hex HMAC-SHA256 of the raw body alone, is unchanged, so a verifier written against it keeps working. Code for both languages is in [Webhooks](/webhooks#signature-verification). ## September 23, 2026: Edit and delete views, filter included Improved. Manage views lists every saved view with Edit and Delete, and the Edit drawer changes a view's filter with the same chips as the page. Changing or removing a saved view no longer means switching to it first to find its settings. * **Manage views** in the view menu on the **Mentions** page lists every view with what it filters, and an Edit and a Delete button on each. Delete asks once, in the same drawer, and never touches a mention. * The view you are looking at has an **Edit** link next to its description under the toolbar, and "Edit" in the view menu. * Editing a view from the list goes back to the list when you save. The Edit drawer changes the filter itself: the same condition chips as the page, so you can add a condition, pick its values, flip "is" to "is not" or remove it, then save the name, description and filter together. Through the API it is still `PATCH` or `DELETE /v1/views/{id}`, and the MCP tools `update_view` and `delete_view`. ## September 23, 2026: Noisy keywords are flagged Improved. Keywords carry a recent relevance read, stats.noise, and the Keywords page flags the ones whose matches are mostly not relevant. Every keyword now reports how relevant its recent matches were, so you can tell when a term is catching more noise than signal. Every match is billed, relevant or not, so a noisy keyword costs more than it tells you. * `stats.noise` on every keyword (`GET /v1/keywords`, `GET /v1/keywords/{id}`, the SDKs, the CLI and the MCP keyword tools): `scored` and `relevant` count the last 14 days of matches the classifier scored, and `noisy` is true once there are at least 20 of them and fewer than 30% were relevant. * The window is recent on purpose: tighten a keyword today and it stops being flagged as its new matches come in, not after hundreds more. On the **Keywords** page, a notice above the list names each active noisy keyword, and its relevant count turns amber with the recent share. Click a keyword in the notice to open its settings, where three fixes are spelled out: * **Required terms**: words that appear when a post is about you, like your product, "API" or "tool". * **Excluded terms**: words from the posts you keep dismissing, like "hiring" or "job". * **Context for the classifier**: one sentence on what the term means for you and what to ignore. ## September 23, 2026: A keyword's context now decides what is relevant Fixed. The sentence you give a keyword now outranks the classifier's general rules, so a keyword that asks for job posts gets job posts. A keyword's context ("Keep posts hiring for this role. Ignore commentary that only names the title.") is your instruction for that keyword, but the classifier treated it as a hint and let its general rules win. One of those rules scores hiring posts low, so a keyword set up to find job leads had every job post filtered out while commentary about the role got through. The context now comes first: * A post that is exactly what the context asks to keep is scored as relevant, even when a general rule would have called it staff news. * A post the context says to ignore, or one that is only near its subject, is filtered, however close the topic. On our test set, job-lead keywords went from 3 of 8 posts judged correctly to 8 of 8. Keywords without context are judged exactly as before. ## September 22, 2026: Engagement counts on X mentions New. Every mention now carries post.engagement (likes, reposts, replies, quotes, views, bookmarks as the platform reported them at ingest), filled for X. Author bio, location and website come with X posts too. A mention's `post` now carries `engagement`: `likes`, `reposts`, `replies`, `quotes`, `views` and `bookmarks`, as the platform reported them when the post was ingested, usually minutes after it was written. A count the platform does not have is `null`, and `engagement` is `null` as a whole for platforms that report none and for posts ingested before today. X fills all six. X posts also bring the author's bio, location and website, which show on the person in the audience like the profile facts GitHub and Bluesky already give. Nothing on the bill moves: both X transports carried these fields with every read and threw them away. ## September 22, 2026: Views, saved filters over your mentions New. Switch between saved views on the Mentions page, save the filters you have as one, read a view through the API with viewId, and filter by keyword kind. A view is a named filter over your mentions: "Negative about us", "Competitor mentions", "Needs a reply". Nothing is materialized; a view selects whatever matches when it is read. * `GET`, `POST /v1/views` and `GET`, `PATCH`, `DELETE /v1/views/{id}`. The filter takes the same fields as `GET /v1/mentions`, as JSON. * `viewId` on `GET /v1/mentions` and on `GET /v1/mentions/export.csv` applies a view's filter, ANDed with the rest of the request. * `keywordKinds` on the mentions list: brand, competitor or topic, so "brand mentions" needs no list of ids that changes as keywords come and go. * MCP: `list_views`, `create_view`, `update_view`, `delete_view`; `search_mentions` takes `viewId` and `keywordKinds`. On the **Mentions** page, the switcher at the left of the toolbar lists your views. A view is the base of the list and the chips narrow it further; once you have filters set, **Create view** saves them under a name, and "Manage" renames, describes, refilters or deletes the active view. A view rides in the URL, so a filtered list is a link. ## September 22, 2026: The dashboard opens on Mentions Improved. The Home page is gone. Signing in, switching workspace and finishing onboarding all land on the Mentions feed, and Analytics keeps the numbers. The dashboard no longer has a Home page. It showed a few tiles, a trend and the newest mentions, all of which live on Mentions and Analytics already, so it was one more click before the feed. Signing in, switching workspace, accepting an invitation and finishing onboarding now land on **Mentions**. An old bookmark or link to the dashboard root goes there too. The numbers are on **Analytics**. ## September 22, 2026: A resumed keyword no longer catches up on the time it was paused Fixed. When a keyword starts again after a day or more, because you unmuted it or because a top-up resumed a paused workspace, it reads back at most one day instead of everything posted while it was off. A keyword that was switched off and came back used to pick up where it had stopped. A workspace paused for lack of balance for ten days would, the moment a top-up resumed it, read those ten days in one go, and every post in them counted as a matched mention. Now a keyword that starts again after a day or more reads back at most one day. That applies when you unmute a keyword yourself, when a top-up resumes your keywords, and when the balance recovers on its own. A shorter pause changes nothing: a keyword you mute and unmute within the day continues from its last check, exactly as before. ## September 22, 2026: New keywords get their Bluesky history again Fixed. The 30-day look-back a new keyword runs now includes Bluesky. When you create a keyword, Mentio reads the last 30 days of each platform so the feed is not empty on day one. On Bluesky that read had been refused: Bluesky now only answers search for signed-in accounts. Mentio searches through its own account now, so a new keyword shows its recent Bluesky posts next to the other platforms. Live Bluesky mentions were never affected. ## September 21, 2026: The API host has a front door New. GET https://api.mentio.dev/ is a setup page with one prompt to paste into any agent, and the same content as Markdown or JSON for programs. Until today a request to the root of `api.mentio.dev` answered "route not found". It now answers the way an API host should: with a page that tells an agent, or the person holding one, how to get set up. **For a person.** Open [api.mentio.dev](https://api.mentio.dev/) in a browser: one prompt to copy into Claude Code, Cursor, Codex, OpenClaw or ChatGPT. The agent registers the MCP server, hands you the browser to sign in, and comes back oriented in your workspace. Under it, every document an integration needs: the reference, the OpenAPI spec, auth.md, the MCP server, the API catalog, llms.txt, the SDKs, the CLI and the Claude Code skills. **For a program.** The same page is Markdown with `Accept: text/markdown` and JSON with any other Accept (a plain `curl https://api.mentio.dev/` gets JSON), carrying the prompt and the links as data. Nothing on the page needs a credential; the API itself, under `/v1`, still does. ## September 21, 2026: Click anywhere on a keyword to open its settings Improved. On the keywords page, the whole row (or the whole card on a phone) opens the keyword's settings drawer, not only the term. The keywords table rows open the settings drawer from anywhere on the row: the kind, the counts, the empty space. The Active switch and the delete icon keep their own click. On a phone the whole card does the same. ## September 21, 2026: Search, filter and sort your keywords Improved. The keywords page gets a search box, Kind, Status and Platform filters, seven sort orders and pages of 20. GET /v1/keywords takes the same filters and returns total. The keywords page now works like the mentions page. Search finds a keyword by its term or by its context. **Filter** adds a condition for Kind (brand, competitor, topic), Status (active, paused by you, paused for balance) or Platform. Sort by newest, oldest, A to Z, most mentions, most relevant, most in the last 7 days or latest mention. The list shows 20 keywords a page, and the view lives in the URL, so a filtered list is a link you can share. The API does the same. `GET /v1/keywords` takes `q`, `kind`, `status`, `platform`, `sort`, `limit` and `offset`, and the response carries `total`, the number of keywords that matched before paging: ```bash curl "https://api.mentio.dev/v1/keywords?kind=competitor&status=active&sort=mentions&limit=20" \ -H "Authorization: Bearer $MENTIO_API_KEY" ``` Nothing changes for an existing client: without parameters the answer is still every keyword, newest first. The MCP tool `list_keywords`, the SDKs and the CLI (`mentio keywords:list --status paused`) take the same parameters. ## September 21, 2026: The keywords table says which platforms a keyword is on Improved. The Platforms column shows the tracked platforms and a count instead of ten inline toggles; changing them moved into the keyword's settings drawer, with labels. The Platforms column of the keywords page used to be ten small icons per row that toggled on click, with "on" shown as a border and "off" as grey, and a paused keyword faded all of them. Three states that looked like one. The column now reads: "All 10 platforms", or the tracked platforms in colour with a count such as "3 of 10". Clicking it opens the keyword's settings, where the platforms are labelled pills you turn on and off, next to the kind, the classifier context and the matching rules. Hovering a platform there still says when it was last polled. ## September 21, 2026: A new keyword no longer matches months of old posts Fixed. The first live check of a new keyword now starts when the keyword was created. Its history is the look-back alone, at most 10 posts per platform. A new keyword gets a look-back the moment you create it: the newest 10 posts per platform from the last 30 days, shown in the feed and the daily digest, never sent as an instant alert. The first regular check that followed did not know about that. With no bookmark for the term yet, it took the newest page the platform returned, whatever its age. On Reddit and GitHub that page could reach months back for a quiet term, and every post in it counted as a matched mention, on top of the look-back. Now a check never reads further back than the keyword has existed, and a keyword never receives a live post published before it was created, also when another workspace has tracked the same term for months. The same holds when you add a keyword for a term that only a muted keyword tracked before: it starts at yours, not at the point the muted one stopped. Nothing changes for a keyword that is already running. ## September 20, 2026: A rate limit, with headers that say where you stand New. 600 requests a minute per workspace on a sliding window, X-RateLimit headers on every response, and a 429 with Retry-After past it. The API had no workspace-wide limit until today, only caps on the two CSV exports. It now has one, and it tells you where you stand on every response. **The limit.** 600 requests a minute per workspace, counted across every API key and OAuth token the workspace holds, on a sliding window: a request stops counting sixty seconds after it was made, so there is no top-of-the-minute cliff. MCP tool calls count into the same window as REST requests. The dashboard's own traffic does not count. **The headers.** Every counted response carries `X-RateLimit-Limit`, `X-RateLimit-Remaining` and `X-RateLimit-Reset` (Unix seconds when the next slot frees), on errors as much as on successes, so a client can pace itself off a 404 too. **Past it.** A request answers `429` with the `rate_limited` code, a `Retry-After` header in seconds and `retryAfterSeconds` in the body. Wait that long and send the same request again; nothing was applied. The CSV exports keep their own cap of 6 a minute each. See [Conventions](/rate-limits) and [Errors](/errors). ## September 20, 2026: Keyword rules, noise filters and your own verdicts, now in the dashboard New. The keyword settings, workspace filters, mention verdicts, language filter, classifier guidelines and key expiry that landed in the API last week have their dashboard controls. Last week's API release added a set of controls that only the API, the SDKs and the MCP tools could reach. They are in the dashboard now. **Keyword settings.** Click a keyword's term, or the sliders icon on its row, to open its settings: its kind (brand, competitor or topic), a one-line context the classifier reads for that keyword only, and the matching rules the matcher applies before a mention is stored: required terms (any or all of them), excluded terms with a `*` wildcard, excluded authors and case sensitivity. A post a rule drops is never classified, delivered or billed. The row shows how many rules a keyword carries. Adding a keyword takes the context line too. **Noise filters.** Settings now has a Noise filters card: excluded terms and authors that apply to every keyword, GitHub repositories to ignore, and a subreddit allow list or deny list. Same guarantee: a dropped post is never billed. **Your verdict on a mention.** The mention drawer's Classification section has Relevant and Not relevant buttons and a sentiment correction. A verdict overrides the classifier's score, so a filtered mention comes back into the relevant feed and the digests, or leaves them. The classifier's original values stay visible, and Withdraw restores them. Nothing is billed or unbilled by a verdict. **Language and type filters.** The feed's Filter menu offers Language (the twenty languages the classifier names, in your own language's names for them) and Type (original posts or replies and comments). **Classifier guidelines.** The company profile takes your website, your competitors by name, and free-text guidelines for the classifier: what counts as relevant for you and what never does. **Key expiry.** A new API key can expire in 7, 30 or 90 days or a year. The keys table shows when, and an expired key reads as such until you revoke it. ## September 19, 2026: A calibrated classifier, six more tags, and a confidence on every verdict New. Verdicts now come from a calibrated model with a confidence score; six new intent and topic tags (churn_intent, bug_report, pricing, hiring, event, promotional); minConfidence on alert rules; a CSV confidence column. **A new judge.** Relevance, sentiment, tags, the automated flag and the language of every mention are now decided by a calibrated model that answers the rubric as typed questions and returns a probability for each answer, instead of a generative model writing JSON. The same post gets the same verdict every time, in a fraction of a second, and it reads competitor posts the way the rubric says: a substantive complaint about a competitor is relevant, however little it mentions you. The one-line note still comes from a generative model, which is handed the verdict and asked only to explain it. **Confidence on the API.** `classification.confidence` (0 to 1) says how sure the classifier was of its relevance verdict, and `classification.uncertain` flags a verdict worth a look: confidence under 0.4, or the note writer disagreeing with it. Neither hides a mention. Alert rules and `GET /v1/mentions` take `minConfidence`; the CSV export gains a `confidence` column. Mentions scored before today, or by the fallback model, carry `confidence: null`. **Six more tags.** `intents` now also carries `churn_intent` (leaving or replacing the keyword), `bug_report`, `pricing`, `hiring`, `event` and `promotional`, in the same list as before, so every intent filter, alert rule, segment and breakdown takes them without a new field. Churn intent and bug reports join buying intent, questions and negative posts in the digest's "needs you" list. The webhooks page offers `mention.churn_intent`, `mention.bug_report` and `mention.pricing` presets. ## September 19, 2026: A long post now keeps the part that mentions you Improved. Long posts are stored as their opening plus the passage around each keyword that matched, instead of the first eight thousand characters. Most posts are short and nothing changes for them. A GitHub pull request is not: it averages six kilobytes, and more than half of them were being cut off at eight thousand characters. That cut kept the wrong half. A dependency-bump description is a table of version numbers, and the sentence that actually mentions your product can sit six thousand characters down, between two commit hashes. A long post is now stored as its opening, which says what the post is, plus the passage around each keyword that matched, which says why it is in your feed. Measured on three hundred real GitHub posts, that is 82% less stored text with the matching sentence present in every single one. You get the same benefit in the feed and in alerts: the excerpt you read is the part that mentions you, and the classifier judges that passage instead of a page of dependency noise. The full post is one click away on the platform, as it always was. One trade-off worth knowing: searching your mentions looks at the text we store, so on a long post it now searches the opening and the passages around your keywords rather than the whole body. Searching for your own keywords is unaffected, since those passages are exactly what is kept. ## September 19, 2026: Analytics reads half as much to draw the same window Improved. The summary counters and reach no longer join the posts table, the median time to done is computed in the database, and a breakdown stops counting the window a third time when its own groups already add up to it. Every analytics number is a pass over the same window of mentions, and three of those passes were doing more work than the answer needed. The headline counters and the reach figure both joined the posts table only to find out who wrote each post, which now rides on the match itself. A breakdown by platform or sentiment counted the whole window again to turn each group into a percentage, although its own groups already add up to that total. The median time to done also changed, and it is more correct than before: it used to pull the five thousand fastest handled mentions and take the middle of those, which is the middle of the fast half once a workspace has handled more than five thousand. It is now computed in the database over the whole window. Measured on a 30-day window in production: the counters went from 6,108 rows read to 3,054, and reach from 8,216 to 5,162. ## September 19, 2026: The alerts and keywords pages stop reading your whole history to draw a number Improved. Two dashboard queries counted every delivery and every mention a workspace had ever had, on every page load. Both are now bounded, and the daily cleanup no longer scans the tables it prunes. Two numbers on the dashboard were being computed the expensive way. The alerts page counted the last seven days of sends by aggregating every delivery the workspace had ever made, and the keywords page counted all-time mentions per keyword on every load, from five different screens. Neither read got slower with traffic; they got slower with age, which is the worse kind. The seven-day count is now a seek over seven days, "last sent" is remembered on the rule itself, and the keyword counters are cached for a minute so a burst of navigation asks once. The daily cleanup got the three indexes it was missing, so it no longer walks the largest table in the database to find the handful of rows that just aged out. Nothing changes in what any of these numbers say. ## September 19, 2026: The audience page stops reading your whole history to draw one page Improved. The people list and the person drawer now group by author without joining the posts table, and only pay for the keyword and link-host joins when a filter asks for them. Listing people meant grouping every match the workspace has by the person who wrote it, and the person lived on the post rather than on the match. So the query walked the workspace's matches and looked up each post just to learn who wrote it, before it could group anything: about 27,500 rows read to return fifty people. The author now rides on the match, the way the date and the platform have since the window reports were fixed. The default list no longer touches the posts table at all, and the joins that remain are paid only by the filters that need them: keywords for a keyword-kind filter, posts for a link-host one. Opening one person went from walking their posts to a single index seek. Measured on production: 27,499 rows read down to 17,075 for the same page, with the biggest gains on the workspaces with the longest history. ## September 19, 2026: A digest that cannot be delivered says so instead of retrying for six hours Fixed. A digest whose channels all failed permanently now finishes and records the failure, rather than rebuilding itself every minute until it gives up. A daily digest is retried on later ticks when a send fails, which is right for a rate limit or a Slack hiccup. It was also doing it for failures that could never succeed: an email channel with no confirmed recipient, a webhook whose URL is gone. Those rebuilt the whole digest every minute for six hours, then marked the run sent without anything being sent, which looked identical to a healthy digest in the dashboard. A run now waits for another tick only when a failure was actually transient. Everything else finishes on the first attempt and keeps the error on the run, where the alert's delivery history shows it. Closing a run is not the same as delivering it. A digest that reached nobody no longer advances the rule's window, so the mentions it could not send roll into the next one instead of falling through the gap. Fix the cause an hour later and tomorrow's digest carries both days. ## September 18, 2026: An Interacted button in Slack closes the mention and says who handled it New. Every Slack alert now carries an Interacted button that marks the mention done and answers in the thread with the name of the person who pressed it. A Slack alert could be read, opened and muted, but not closed: the only way to mark a mention handled was to leave Slack and open the dashboard, and nothing recorded who had taken it, so two teammates could answer the same post without knowing. Every instant alert now carries an **Interacted** button. Pressing it marks the mention done and posts a line in that message's thread saying who pressed it, so the channel itself shows what is still waiting. Because one Slack message stands for a post however many of your keywords it matched, it closes every match of that post at once, and it appends a line to the mention's note ("Interacted by Miki via Slack, 2026-09-18") that you can read later in the dashboard. The buttons stay exactly as they were after a press, so a second person can press Interacted too: each press adds its own line in the thread and its own line in the note. The first press is what counts as the time to done. ## September 18, 2026: Keyword settings and workspace filters decide what gets stored New. Required and excluded terms, excluded authors, case sensitivity and a classifier hint per keyword; workspace-wide noise rules; a rejected post is never billed. A common word no longer has to be a noisy keyword. Every keyword takes `matching` rules: terms the post must also contain (any of them, or all of them), terms that drop it (with a `*` wildcard at an end, so `beta.*` catches every build number), authors to skip in the same forms an alert's mute list takes, and `caseSensitive` for an acronym like `RAG`. A keyword also takes a `context` sentence the classifier reads for that term alone ("Arc is our browser; ignore the geometry word"), and its `kind` can now be changed after creation. The whole workspace gets its own noise rules at `GET` and `PATCH /v1/filters`: terms and authors excluded for every keyword, GitHub repositories, and subreddits to allow or deny. Both layers run in the matcher before a mention is stored, which is what makes them different from an alert's filter: a post they reject is never classified, never delivered and never billed. Deleting a keyword now also takes it out of every alert rule that named it, and disables a rule that named only that keyword instead of quietly widening it to everything. MCP: `add_keyword` and `update_keyword` take the new fields; `get_keyword`, `delete_keyword`, `get_filters` and `update_filters` are new. The CLI gains `filters:get` and `filters:update`. Guide: [How it works](/how-it-works#matching-rules). ## September 18, 2026: Overrule the classifier, weekly digests, the team and the balance over the API New. Relevance and sentiment verdicts on a mention, post language, weekly digests, key expiry, whoami, usage, members and invitations, competitors and guidelines on the company profile. **Your verdict on a mention.** `PATCH /v1/mentions/{id}` takes `relevant: true` or `false` and a corrected `sentiment`. The verdict is written through: a mention marked noise leaves the relevant feed, the digests, the counts and the analytics; one the classifier missed comes back in. `null` withdraws it and restores the classifier's value, which `classification.feedback.original` kept. Every keyword reports its verdicts under `stats.feedback`. Verdicts never bill or unbill anything. **Language.** The classifier now returns the post's language (ISO 639-1) with the rest of the verdict, at no extra cost. It is on every mention (`classification.language`), filters the list (`languages`, `notLanguages`), narrows an alert rule (`filter.languages`), rides in the CSV and groups a new analytics breakdown (`by=language`). **More filters and reports.** `GET /v1/mentions` takes `maxFollowers`, `isReply` (replies against top-level posts), `alertId` (the same mentions an alert rule would send) and searches the author's name with `q`. Analytics series split `by=sentiment` and bucket by `hour` (for a launch day) or `month`. **Weekly digests.** An alert rule can be `weekly`: one digest a week on `schedule.weekday`, covering the week. **Run now** sends the rule's own period. **Credentials and the team.** `GET /v1/whoami` introspects the credential (workspace, kind, scope, a key's expiry). API keys take `expiresAt`. `GET /v1/members`, `GET` and `POST /v1/members/invitations`, `DELETE /v1/members/invitations/{id}` and `DELETE /v1/members/{id}` manage the team; changes need a signed-in owner or admin (an OAuth token or the dashboard session, not an API key), and an invitation sent over the API is accepted the same way as one from the dashboard. `GET /v1/usage` answers the money question in one read: balance, burn, days left, keywords running and paused, matches today. **Company profile.** `competitors`, `guidelines` (free-text rules for the classifier) and `website` join the profile and are composed into the context. MCP gains `whoami`, `get_usage`, `list_members`, `get_alert` and `delete_alert`; the CLI `auth:whoami`, `usage:get` and the `members:*` commands. Guides: [How it works](/how-it-works#your-verdict), [Alerts](/alerts#daily-and-weekly-digests), [Authentication](/authentication). ## September 18, 2026: A filter dropdown no longer changes shape while you are using it Fixed. The searchable filter dropdown stopped swapping forms mid-selection, greys an empty selection again, and names itself to screen readers. The searchable filter dropdown, added a few days ago, changed form the moment its list crossed six options. A keyword list that grew while the dropdown was open (another tab adding a keyword, or a refresh landing) rebuilt the popup under the pointer. It now changes form only while closed, so what you are picking from stays put. Two smaller things went with it. A filter pointing at something that no longer exists, a bookmarked link to a deleted keyword, reads "Any keyword" again in grey rather than in full black, so it no longer looks like a live selection. And the list now tells a screen reader which filter it belongs to ("Keyword") instead of reading back the current selection. Long lists are also cheaper to open: the options are built once per page rather than on every render, which is what the keyword filter of a workspace tracking hundreds of them was paying for. ## September 16, 2026: Mentions from bots are labelled New. The classifier says whether a post reads as machine-made, and every surface can filter on it. * Every mention carries `classification.automated`: true when the post reads as machine-made (a bot or app account, a scheduled or templated post, generated text). It comes from the classifier's existing pass over the text plus the account itself, so a GitHub App or a handle like `release_bot` is caught even when a single post reads human. * Filter with `GET /v1/mentions?automated=true` (or `false` for everyone else), in the feed's new Automated chip, and in alert rules through the `automated` filter, so a rule can watch the bots or keep them out of a channel. * The audience and segments filter by `automated` too: a person counts as a bot when most of their matched posts do, which is how you tag or mute a whole account. * It labels, it never hides: nothing is dropped from the feed or from delivery, and every matched mention is billed as before. Mentions classified before today read as not automated, so no filter makes old mentions disappear. ## September 16, 2026: Alerts say what the mention is, and sentiment follows the keyword Improved. Every alert used to open with the same line whatever it was about, so a competitor rant and a piece of praise looked alike in Slack. An alert now leads with the mention itself: the strongest signal first (a buying signal, a comparison, a complaint, a question, praise), otherwise the sentiment, always naming the keyword that matched. Slack shows it as the message header, Telegram as the first line, email as the subject. The classifier also stopped reading the mood of a post as an opinion about your keyword. A tool named once inside an angry story, a competitor cited in a link or a hashtag, or a friendly reply on a thread about your pricing used to come back negative with a complaint intent. Sentiment and intent are now judged from what the text actually says about the keyword, and a keyword that only appears in a link, a hashtag, a handle list or a list of tools is scored as the passing mention it is. Measured against a set of real mentions, correct verdicts went from 27 in 45 to 38 in 45. ## September 16, 2026: Filter dropdowns you can search Improved. Picking a keyword or a platform in the mentions and audience filters meant reading a list that grew with your workspace, and a list of keywords ran off the bottom of the screen. Once a filter holds more than six options its dropdown now opens with a search field and scrolls at six rows, so you type two letters instead of scanning. Shorter lists are unchanged. ## September 16, 2026: The daily digest reads by platform Improved. The digest's platform split is now a block you can scan: each platform with its own logo, the count in full size, and how it moved against the day before (a platform with nothing yesterday reads "new"). Underneath, both lists group their mentions by platform, so you answer the X posts, then the Reddit threads, instead of switching platform on every row. ## September 16, 2026: The outreach line in a mention shows up only when it has something to say Improved. Opening a mention showed an outreach line on every author, and on most of them it only said "Not contacted · No owner". It now appears when a teammate owns the person, their stage has moved, or someone logged a contact, which is when it matters: a highlighted line that keeps you from reaching out to somebody a teammate is already talking to. On everyone else the Triage card carries a quiet "Log a contact" link into their outreach log. ## September 16, 2026: The SDKs page shows every client, its install line and its repository Improved. The docs' SDKs page was a table of language names. It now opens with a card per published client, each with the language's own logo, the package, the install command, and links to the guide, the source repository on GitHub and the registry. The languages with no official client yet keep their own row, next to the three ways to work in them today. Sidebar entries for the clients carry their language logo, so the section reads as a list of languages, and the Markdown twin at `/sdks.mdx` lists the same packages and repositories as a table for anything reading the docs as text. Changelog also sits with the other sidebar entries now, with an icon, instead of floating alone under a blank gap. ## September 16, 2026: A team invitation no longer gets lost on the way through sign-in Fixed. Opening an invitation link, starting a Google sign-in, going back and signing in again could land you in a new empty workspace instead of the team's, with the invitation still unaccepted. When a sign-in is needed on the way, it now returns you to the page you were on. Workspace setup also lists pending invitations for your verified email address, so you can join the team from there even if you signed up without the link. ## September 15, 2026: Alert when a post links to a competitor, a partner or you New. The links in a post are now a filter on alert rules and on the audience, not only on the feed, and a host now covers its subdomains. Yesterday a mention started carrying its links. Today they are something you can be told about. An alert rule takes a **Links to** list. Put a competitor's domain in it and their next mention in someone's post is a Slack message; put your affiliate short domain in it and you hear when a partner actually uses their link. ```bash curl -X POST "$MENTIONS_API_URL/v1/alerts" \ -H "Authorization: Bearer $MENTIONS_API_KEY" -H "Content-Type: application/json" \ -d '{ "name": "Competitor links", "mode": "instant", "filter": { "linkHosts": ["octolens.com"] }, "channelIds": ["dest_…"] }' ``` The same filter is now on the audience: `GET /v1/people?linkHosts=octolens.com` is the people who have shared such a link, and it saves as a segment. On the mentions page **Links to** is a filter you can add yourself, not only a chip that arrives when you click a link in a mention. One rule changed for everyone. A host entry now names a company rather than one server: `octolens.com` matches `blog.octolens.com` too, a pasted URL and a `www.` prefix read as the same host, and the dot boundary keeps `t.co` from matching `not.co`. A post with no links never matches a link filter. The query parameter is `linkHosts` everywhere, in the API, the CLI (`--linkHosts`), the SDKs and the MCP tools. ## September 15, 2026: Outreach on people, so two teammates never contact the same person New. An owner and a stage on every person, and a log of who reached out, when and how. * Every person carries `outreach`: the teammate who owns the contact, a stage (`not_contacted`, `contacted`, `replied`, `in_talks`, `customer`, `not_a_fit`) and when someone last reached out. Set the owner and the stage with `PATCH /v1/people/{id}` (`ownerId`, `stage`). * `POST /v1/people/{id}/activities` logs a contact: the channel (email, X, LinkedIn, a call...), a short note and who made it. The first one claims an unowned person and moves them to `contacted`; an owner is never taken away. `GET` lists the log across all of the person's accounts and `DELETE /v1/people/{id}/activities/{activityId}` removes a mistake. * `GET /v1/people` and segments filter by `stages` and `ownerIds` (`none` for people nobody owns), and the people CSV gains stage, owner and last contacted columns. * On the MCP server, `update_person` sets the owner and stage, and `list_activities`, `log_activity` and `delete_activity` work the log. ## September 14, 2026: A changelog, with an RSS feed New. This page. One entry per user-facing change, newest first. What changes in Mentio is now written down in one place: this page, newest first, with a tag for what kind of change it is. Subscribe at [/changelog/rss.xml](/changelog/rss.xml); agents can read it as Markdown at `/changelog.mdx` or with `Accept: text/markdown`. ## September 14, 2026: Every mention now carries the links in the post, and you can search by them New. post.links on every mention, and a linkHosts filter that answers "who is linking to my docs, my pricing page, a competitor". A mention now carries the links its post contains, in the order they were written, as `post.links`. Nothing was fetched to build this: the text was always stored, so the links were always there, just not reachable. The point of it is the filter. `GET /v1/mentions?linkHosts=docs.mentio.dev` returns the posts linking to a host, any-of, `www.` ignored: ```bash mentio mentions:search --linkHosts docs.mentio.dev,mentio.dev ``` It works in the API, the CLI, the SDKs and the `search_mentions` MCP tool, and `links` is a column in the CSV export. Existing mentions were backfilled from the text already stored, so the filter reaches your whole history, not only what arrives from now on. ## September 14, 2026: Mentio on GitHub, with the SDKs, the CLI and Claude Code skills as public repositories New. github.com/mentio-dev holds read-only copies of the TypeScript SDK, the Python SDK, the CLI and the OpenClaw skill, plus a new repository of Claude Code skills. * [mentio-dev/sdk](https://github.com/mentio-dev/sdk), [mentio-dev/sdk-python](https://github.com/mentio-dev/sdk-python), [mentio-dev/cli](https://github.com/mentio-dev/cli) and [mentio-dev/openclaw-skill](https://github.com/mentio-dev/openclaw-skill) are published from the main codebase on every release, tagged with the version. The npm and PyPI package pages now link to them. * [mentio-dev/claude-skills](https://github.com/mentio-dev/claude-skills) is new: the `/reddit-morning` skill from [the Reddit playbook](https://mentio.dev/blog/find-customers-on-reddit/), a `CLAUDE.md` template with the reply rules, and install steps. * Issues are welcome on any of them. Changes land upstream and are mirrored back. ## September 14, 2026: A roomier mention drawer Improved. The mention drawer is wider on desktop. Triage is one card with the assignee and snooze side by side and the note underneath, and the classification opens with four tiles (relevance against the delivery threshold, priority, sentiment, reach), then the intents and author tags as chips and the classifier's reasoning. Keywords also moved up in the sidebar, right under Mentions. ## September 14, 2026: Filter mentions by intent Improved. The Mentions page has an Intent filter next to Sentiment: buying intent, question, complaint, praise or comparison. It is the same `intent` parameter `GET /v1/mentions` already accepts, so a filtered view in the dashboard and a call to the API return the same mentions. ## September 14, 2026: Segments as a table Improved. The Segments page lists your saved segments as a table: the name and description, what the filter says, how many people qualify right now and when it last changed, with View people, CSV and Edit on every row. Clicking a row opens the editor. Presets sit underneath as a compact list, each one saved with Use preset. ## September 14, 2026: The daily digest reads like a to-do list, not four copies of the same thing Improved. Two lists instead of four overlapping sections, the keyword on every row, and the sentence that actually matched. The daily digest used to show Priority, Negative, Buying signals and Questions as four separate sections over the same mentions, so a single post could appear three times. It is now two lists and each mention sits in exactly one of them: * **Needs you today**: buying intent, a question, or an unhappy post. * **Also worth a look**: everything else, best first. Three more changes on every row and in the header: * Each row names the **keyword** it matched, so ten tracked terms stay apart. * Each row quotes the **sentence that matched** instead of the first 280 characters, which on LinkedIn and GitHub used to be the author's headline or a pull request template. * The header adds a per-keyword split next to the per-platform one. People you muted on the Audience page no longer appear in a digest, the way they already stayed out of the feed and instant alerts. Muting your own team is now the one place to stop hearing about yourselves. The same two lists render in the Slack and Telegram digests; the digest webhook payload is unchanged. ## September 14, 2026: Changing a member's role could fail on older workspaces Fixed. Memberships created before workspaces gained their current member table could carry no id, and the Team page then answered a role change or a removal with a validation error. The affected rows were repaired and the table now refuses a missing id. ## September 14, 2026: Confirming an email channel failed with an internal error Fixed. The link in the confirmation email answered `internal_error` instead of confirming the address: the API matched it against the "get one channel" route and read `confirm` as a channel id. Confirmation links work again, and the ones already sent are still valid until they expire. ## September 14, 2026: Joining a team no longer leaves an empty workspace behind Fixed. Every new account gets a workspace of its own at sign-up, so someone who signed up through a team invitation ended up with the team's workspace and an empty personal one. Accepting an invitation now removes that personal workspace when nobody ever used it: no keyword, no onboarding, no top-up, no other member. A workspace that was used stays. ## September 13, 2026: Sign in with GitHub, and a shorter sign-in page New. Google and GitHub come first; email sign-in sits behind a toggle. * **GitHub** joins Google as a sign-in provider. An existing account signs in with whichever it used before; nothing changes for email sign-in. * The sign-in and sign-up pages are one card: the two providers first, then "Continue with email" for the magic link, and the terms line under it. ## September 13, 2026: MCP sign-in from Claude Code works end to end Fixed. Three things stood between `claude mcp add` and a working session and all three are gone: the authorization server discovery document is now answered for the exact resource path Claude Code asks about, the consent page no longer sends a doubled `Content-Type`, and the consent page names the client that is asking, with its mark, before you pick a workspace. Guide: [MCP server](/mcp). ## September 12, 2026: A request id on every response and one catalog of error codes New. Quote the id to support; read the code, not the message. * Every API response carries `X-Request-Id`; an inbound one is honored when it is 8 to 64 URL-safe characters. Error bodies repeat it as `error.requestId`, and the dashboard's error messages show it. * Every error code is stable and documented on the [Errors](/errors) page, generated from the same catalog the API answers from, with its status and who has to act. A failing upstream platform now answers `502 upstream_unavailable` instead of a generic 500. ## September 12, 2026: Sign in to the MCP server with your account New. OAuth 2.1 with PKCE and dynamic client registration; API keys keep working. Clients that support OAuth (Claude Code, Cursor, claude.ai, ChatGPT and others) can now connect to `https://mcp.mentio.dev/mcp` with a sign-in instead of a pasted key. The flow opens the browser, signs you in, and lets you choose the workspace the client acts on; scopes are `read` and `write`, the same as API keys. A key still works everywhere a token does. Guide: [MCP server](/mcp). ## September 12, 2026: One billing customer per person, shared by their workspaces Improved. A person's workspaces now share one billing customer and one card list, so a card added in one workspace is available in the others. Receipts stay per workspace. A second workspace no longer receives a welcome credit; it starts with a funding step and runs once it has a balance. Details: [Billing](/billing). ## September 11, 2026: Documentation an agent can read, and a skill for OpenClaw New. Every page as Markdown, llms.txt, a documentation MCP server and the mentio skill on ClawHub. * Every documentation page exists as Markdown at `/.mdx`, and a request with `Accept: text/markdown` on the page URL gets it directly. The index is at `/llms.txt`, the whole site in one file at `/llms-full.txt`. * A read-only documentation MCP server at `https://docs.mentio.dev/api/mcp` answers `search_docs`, `read_page` and `list_pages`; no key needed. * The [OpenClaw skill](/integrations/openclaw) is on ClawHub as `mentio`: one file the agent reads first and one rule file per API area, the reference parts generated from the OpenAPI document. ## September 10, 2026: TypeScript SDK, Python SDK and CLI New. @mentio-dev/sdk and @mentio-dev/cli on npm, mentio on PyPI, all generated from the OpenAPI document. * [TypeScript](/sdks/typescript): `npm install @mentio-dev/sdk`, one function per endpoint with request and response types, `{ data, error }` results or `throwOnError`. * [Python](/sdks/python): `pip install mentio`, one object with a call per endpoint, sync and async, typed. * [CLI](/cli): `npm install -g @mentio-dev/cli`, every endpoint as a `noun:verb` command, `mentio auth:login` through the browser, `mentions:watch` for a live feed as JSON lines, `mcp:config` for the client block. All three are regenerated and published whenever the API changes, so they are never behind it. ## September 10, 2026: One design for every email Mentio sends Improved. Account emails, wallet notices, instant alerts and daily digests now share one layout in the brand type and palette, with the help link and, on alerts and digests, a manage-notifications link in the footer. The founder's short notes about getting started arrive from a personal sender with one-click unsubscribe and never go to anyone who opted out. ## September 9, 2026: Prices in US dollars, top-ups from $20 Improved. The balance, the rates and the checkout are in USD: $5 per keyword per month, $0.008 per matched mention, top-ups of any amount from $20 up to $5,000. Existing balances were converted at the day's rate. Details: [Billing](/billing). ## September 7, 2026: A prepaid balance instead of plans New. No plans, no seats, no tiers. A balance, two rates, and a welcome credit. * Every workspace holds a balance. Keywords cost $5 per month, charged per day; every matched mention costs $0.008 whether it turned out relevant or not, and the dashboard shows both counts so the balance never disagrees with the feed. * Every new account starts with $5.80 of credit: one keyword for a month plus 100 mentions, no card. * When a balance cannot cover the next day, keywords pause and resume on their own after a top-up; you get an email at 20% of your last credit and at the stop. Details: [Billing](/billing).