App-only daily offers are missing from the parsed dashboard

[topsq]

Daily "Rewards app only" offers are invisible to the script — and can't be earned from the web

Since 2026-09-04 the dashboard shows 5 extra daily offers worth 10 points each
(offerId pattern: WW_Moreactivities_RewardsApp_offer_YYYYMMDD_1..5), titled
"... (only in the Rewards app)". The web UI shows them as locked.

Two separate findings:

1. The script never sees them. They ARE present in
   rewards.bing.com/api/getuserinfo?type=1 under dashboard.morePromotions, and
   they pass MorePromotions.isActionable() as written:
   complete: false
   pointProgressMax: 10
   promotionType: "urlreward"
   priority: 1
   exclusiveLockedFeatureStatus: "notsupported" (note: not "locked")
   attributes.is_unlocked: "False"
   But they are absent from the dashboard payload the bot bootstraps, so
   MorePromotions reports "remaining=3" while the API lists 8 actionable items.
   I confirmed this by diffing API snapshots taken before and after a run.

2. Even so, they look deliberately gated: every destinationUrl of these offers
   carries &rnoreward=1, which regular urlreward offers do not. Completing them
   manually in the Rewards app sets complete: true and awards the points, while
   attributes.is_unlocked stays "False" — so that field means "reachable from
   the web", not "done".

Two questions:

a) Is it worth surfacing these somewhere (e.g. a log line saying N app-only
offers were skipped), so users understand why ~50 points/day appear to be
missing? Right now the script is silently correct but looks broken.

b) Do you see any legitimate route to completing them without the app, or is
rnoreward=1 a hard gate by design? If it is a hard gate, I'd rather have it
documented as out of scope than have people chase it.

Side note: is_unlocked is declared in DashboardData.ts but never read anywhere.

[2oTA]

Yes, they suddenly changed part of the completion requirements. Now you have to complete the tasks through the Rewards app in the Microsoft Store. I'm not sure how to handle this.

[shmily1866]

This seems to be a new type of activity, so I’d like to request support for it.🙏😊

[phanex]

b) Do you see any legitimate route to completing them without the app

There is. You need to perform any Bing search, press this button to call rewards sidebar:

And here is it:

[TheNetsky]

I'm currently unavailable till Sunday, after I will be back to look at this and other issues.

[TheNetsky]

I'll be looking into this.

[phanex]

It looks like all these things are now in the "Earn" tab rather than the dashboard: https://rewards.bing.com/earn

[LepaBrenaa]

@phanex is there a way for me to contact you? I got a question regarding your setup since you seem to be from the same country as me.

[topsq]

Update: the format changed on 2026-09-27, so the details in my original report are outdated.

The daily WW_Moreactivities_RewardsApp_offer_* offers are gone. They were replaced by a weekly punch card, up to 70 points per week (Italian UI title: "Missione esclusiva settimanale dell'app Rewards").

• Location: dashboard.punchCards in rewards.bing.com/api/getuserinfo?type=1, no longer morePromotions
• Parent: WW_pcparent_RewardsApp_weekly_Exclusive_Septw4_2026_punchcard
• 8 children: WW_pcchild{N}_urlreward_{Day}_RewardsApp_weekly_Exclusive_Septw4_2026_punchcard, where {Day} is Install, then Sunday … Saturday

Snapshot taken on 2026-09-29 (a Tuesday):

child  day        complete  points  attributes.is_unlocked  rnoreward=1 in destination
1      Install    true      0/0     (absent)                no  (it's the "install the app" link)
2      Sunday     true      10/10   "False"                 yes
3      Monday     true      10/10   "False"                 yes
4      Tuesday    true      10/10   "False"                 yes
5      Wednesday  false     0/10    "False"                 yes
6      Thursday   false     0/10    "False"                 yes
7      Friday     false     0/10    "False"                 yes
8      Saturday   false     0/10    "False"                 yes

Still true from the original report:

• all children are promotionType: "urlreward", and the seven daily ones still carry rnoreward=1, so opening them from the web doesn't award points
• attributes.is_unlocked stays "False" even on completed children, so it can't tell which ones are available

New:

• one child unlocks per day starting on Sunday. The weekday is only encoded in the offerId; the web panel shows future ones with a padlock
• the /earn RSC payload only contains the parent, the children are only in getuserinfo
• the children don't appear in the Bing flyout response (/rewards/panelflyout/getuserinfo?channel=BingFlyout) either, so the sidebar route mentioned above may not apply to the new format. I only checked the response, not the sidebar UI itself.

As far as I can tell, #612 targets the /earn cards and Explore on Bing rather than these app-only activities, so this issue probably shouldn't be closed by it.

[phanex]

As far as I can tell, #612 targets the /earn cards and Explore on Bing rather than these app-only activities, so this issue probably shouldn't be closed by it.

Thanks for the detailed update.

You were completely right that PR #612 initially only addressed the new /earn RSC payload and Explore on Bing.

However, I just pushed an update to the PR branch that specifically resolves the new weekly RewardsApp punch card. The problem with these cards was in PunchCards.ts: isClaimChild was matching reward inside WW_pcchild{N}_urlreward_..., mistakenly classifying these daily activities as reward claim buttons and trying to POST to the claim endpoint instead of running them.

With that fixed, the bot now correctly recognizes and executes the unlocked daily children as regular UrlReward activities, allowing them to credit properly day by day.

So PR #612 now covers both the /earn tab overhaul and this weekly RewardsApp punch card, directly addressing #603.