Badoo Subscription Prices by Country and App Store Ratings avatar

Badoo Subscription Prices by Country and App Store Ratings

Pricing

from $5.00 / 1,000 storefront snapshots

Go to Apify Store
Badoo Subscription Prices by Country and App Store Ratings

Badoo Subscription Prices by Country and App Store Ratings

Live Badoo Premium, Super Powers and Credits prices by country from the App Store and Google Play, converted to USD, with ratings and change tracking between runs.

Pricing

from $5.00 / 1,000 storefront snapshots

Rating

5.0

(1)

Developer

Tim Zinin

Tim Zinin

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

14 days ago

Last modified

Share

Badoo App Intel — Subscription Prices by Country and App Store Ratings

Badoo's own Premium subscription prices, Super Powers boosts and Credits pack prices, read straight from Badoo's own App Store and Google Play listings for any country you name, converted to USD where a rate exists, and compared across storefronts, plus the app's rating, version and release notes — no login, no API key, no profile data, only what Badoo itself already publishes on its own public store page for every visitor to see.

Badoo is owned by Bumble Inc. (NASDAQ: BMBL) — the same public company behind this line's own Bumble Actor — but prices and names its own tiers completely differently: Badoo sells "Super Powers" and packs of "Credits" where Bumble sells Boost and BumbleCoins, and Badoo's own Google Play listing is, by rating count, the single largest storefront in this entire five-brand line after Tinder's — 6,652,938 ratings and a 100M+ install bucket at the time this README was written. This Actor reads Badoo's own real numbers directly, with its own distinct plan dictionary, never assuming Bumble Inc.'s other brand's naming applies here.

What you get

  • Badoo's own priced plan and pack list, read off the live page, not guessed at. inAppPurchases[] on an App Store row carries every entry that storefront's own page actually shows — Badoo Premium, 7 Days Badoo Premium, Super Powers,
    Pack of 100 Credits
    , 250 Badoo Credits — at that country's own price, in the same wording the store itself uses. Nothing here is a marketing-page estimate; it's the live IAP feed itself.
  • planFamily normalizes every real naming variant this brand's own pages use, with a single flat key covering every prefix. Badoo Premium, plain Premium, and
    7 Days Badoo Premium
    all collapse to planFamily: "Premium" from one 'premium' dictionary key — unlike Bumble's own dictionary, which needs a longer premium+ key checked first to avoid misclassifying a Premium+ name, Badoo's own real IAP list has never shown a tier with a + or any other name that would collide with the plain premium substring, so one key correctly covers every variant with no ordering risk at all.
  • Every numeral in a Credits pack name is a quantity, confirmed against real captured data, never mistaken for a duration. Pack of 100 Credits, pack of 100 Badoo credits, pack of 550 Badoo credits and 250 Badoo Credits are all real, live-captured names — every one of them has durationDays: null, because this Actor's duration parser only ever fires on an explicit day/week/month/year unit word inside a plan's own name, and NEVER infers a duration from a bare number regardless of how large it is. 100, 250 and 550 here are quantities of credits, not lengths of time, and this Actor's field dictionary states this explicitly rather than leaving a reader to wonder whether "550" might mean "550 days."
  • The exact same numeral pattern, contrasted directly against a real duration-stating name from the same brand. 7 Days Badoo Premium — captured live alongside the Credits-pack names above — DOES get durationDays: 7, because THIS name states an explicit unit word ("Days"). Reading the Credits examples and the 7 Days Badoo Premium example side by side in this README's own Output section is the clearest possible demonstration that this Actor's duration logic keys off an explicit unit word in the text, never off the number's own size or the plan's own price.
  • USD conversion, honestly null when the source currency has no published rate. Set convertToUsd (on by default) and every priced entry gets a usd field from yesterday's ECB daily reference rate — GBP has a real rate, so every UK example in this README carries a real usd figure; a currency the ECB doesn't carry gets usd: null with an explanatory fxNote instead of a silently wrong number.
  • Track price and rating changes over time, per storefront. Set compareWithPreviousRun and a watchId, and every subsequent row for that pair carries a changes[] array of new or removed plans, price moves, rating moves of 0.05 or more, and version bumps.
  • Google Play's own real shape, not a forced match to the App Store's. One aggregate iapPriceRange ($0.49–$239.99 at capture time), no named plans, and containsAds: true — a real, disclosed fact this Actor reports plainly rather than omitting.
  • Independent storefront reads. Every country × platform pair is fetched on its own.
  • Canonical-id validation before anything is trusted. Every App Store page this Actor reads is checked against the numeric id it was asked for (351331194) before any field is parsed out of it, failing closed as source_error rather than silently trusting a mislabeled or redirected page.
  • A run-level free summary, not just per-row data. Every run writes an OUTPUT key to the key-value store — storefrontsBilled, storefrontsFree, partial, rateLimitedStorefronts, notAvailableStorefronts — so you can tell at a glance whether a run fully succeeded without reading every row in the dataset.
  • Runs on Apify: schedule it, call it from the REST API or an SDK, wire it to a webhook, or export straight to JSON, CSV or Excel — see Integration recipes below.

Who uses it

  • Equity and credit analysts covering Bumble Inc. (NASDAQ: BMBL). Badoo is Bumble Inc.'s second major brand alongside Bumble itself, with its own separate revenue disclosure line in the company's own filings; a pricing-power read for Badoo specifically, kept separate from Bumble's own numbers, is a primary-source input this Actor makes directly comparable to this line's own Bumble Actor output, brand by brand.

  • Competitor product and pricing teams at Tinder, Bumble, Hinge, Twinby and any other dating app pricing against Badoo's Premium/Super Powers/Credits ladder, particularly in markets where Badoo's own 100M+ install base makes it the single most-established competitor to price against.

  • ASO and mobile-growth agencies tracking rating trend and review velocity for a portfolio that includes Badoo — one of the largest dating apps by Google Play rating count this entire line covers — who want subscription pricing folded into the same report.

  • Analysts studying Bumble Inc.'s own multi-brand portfolio strategy, comparing how the same parent company prices and names tiers differently across its two major brands (Badoo's Super Powers/Credits vs. Bumble's Boost/BumbleCoins) as a real case study in brand-specific pricing and naming decisions within one company.

  • Currency and purchasing-power researchers using Badoo Premium's real per-country price ladder as one comparable input alongside this line's other four brands.

  • Anyone tracking their own Badoo Premium or Credits-pack cost across a relocation via this Actor's own dataset history.

  • Investor-relations and comms teams at Bumble Inc. itself, who may want an externally-sourced, independent read of what Badoo's own storefronts actually show in a given market — the same public data an outside analyst would see, useful for confirming a pricing change reached every intended storefront as planned.

  • Data-engineering teams building their own quantity-vs-duration parsing logic for any free-text plan-name field, who want a concrete, real, already-solved example — Badoo's own Credits-pack names, contrasted against its own duration-stating Premium name in the SAME live capture, are a usable reference case for exactly this class of parsing decision.

This Actor does not serve anyone looking for Badoo user profiles, photos, messages, match data, or any other personal information about Badoo's own users — see "What this is NOT" under Evidence and boundaries.

How to run it

  1. Click Try for free — no card required, and the default input below runs without any secret or account of your own.
  2. Pick your Countries — ISO-3166 alpha-2 codes, lowercase. The default (us, gb) captures both real currencies this README's own examples use.
  3. Pick your Platforms — appstore, googleplay, or both (the default). There is no rustore option — Badoo is not sold through RuStore.
  4. Leave Convert prices to USD on unless you want each storefront's own local currency only.
  5. Press Start. The default input finishes in well under a minute; a longer country list against Apple, at this Actor's own pace, takes longer — see Operating guide.
  6. Pull the results from the Dataset tab, or read the free run-level summary from the Key-value store tab under the OUTPUT key.

Pricing

Pay-per-event, on the platform's standard PAY_PER_EVENT model: $0.005 charged once at run start, plus $0.005 per storefront that came back with real data (status: "ok", found: true — the platform's own internal event name for this is result-found). Every other outcome is free: a country the app is not sold in (not_available_in_country), a source that did not answer after retries (rate_limited), a real parsing/source error (source_error), or an invalid country code (invalid_country).

The default prefill — two countries, two platforms, so up to four storefronts — resolves to $0.005 + up to 4 × $0.005 = up to $0.025; Badoo has resolved successfully on every one of those four combinations in this line's own testing. Ten resolved storefronts comes to $0.055. maxStorefronts (default 10, maximum 120) caps how many combinations one run will ever attempt, enforced before any request is made, with a free status: "truncated" row naming exactly what was skipped — never a silent drop, never a charge for work that never happened.

At startup, the Actor checks that result events are configured as paid events and that ordinary dataset writes are free. It reads the event price once at startup. Before each successful storefront row, it uses that price snapshot and reads the remaining run budget from the Apify SDK. It does not compare the configured prices with the numbers printed on this page. The live Pricing tab is authoritative; set a maximum run charge to bound your spend.

Input contract

FieldRequiredWhat it does
countriesnoISO-3166 alpha-2 codes, lowercase, e.g. ["us","gb"]. 1 to 60 codes, deduplicated regardless of casing/whitespace. An invalid code returns a free invalid_country row; a code the app genuinely isn't sold in returns a free not_available_in_country row — neither has appeared in this line's own live testing of Badoo across the countries checked so far, unsurprising given the app's very large, global install base. Default: ["us"].
platformsnoappstore, googleplay, or both. Default: both.
convertToUsdnoWhen true (default), priced App Store entries get a usd field from yesterday's ECB rate; null with fxNote for a currency the ECB doesn't carry. When false, no FX lookup runs at all.
compareWithPreviousRunnoWhen true, diffs each row against the last run of that exact country/platform pair under the same watchId. Default: false.
watchIdnoNames which saved snapshot history to diff against. Pattern: [a-zA-Z0-9_-]{1,40}. Default: "default".
maxStorefrontsnoHard ceiling on countries × platforms, enforced before any request. Range: 1 to 120. Default: 10.
{
"countries": [
"us",
"gb"
],
"platforms": [
"appstore",
"googleplay"
],
"convertToUsd": true
}

Real happy, partial and failure output

One row per country × platform pair. Every example below is real and unedited, copied as-is from an actual run of this exact code.

Happy path: a storefront that came back with real, priced data

App Store, United States — the full plan list this page carried at capture time, including two Credits-pack names (Pack of 100 Credits, pack of 100 Badoo credits) both correctly showing durationDays: null, contrasted directly against 7 Days Badoo Premium, which correctly shows durationDays: 7:

{
"recordType": "storefront_snapshot",
"brand": "badoo",
"platform": "appstore",
"country": "us",
"appId": "351331194",
"observedAt": "2026-09-26T15:37:17.512Z",
"status": "ok",
"found": true,
"appTitle": "Badoo Dating: Meet New People App",
"rating": 4.6,
"ratingCount": 148804,
"ratingHistogram": {
"1": 8145,
"2": 1808,
"3": 4008,
"4": 17113,
"5": 117730
},
"version": "5.479.0",
"lastUpdated": "2026-09-17T10:22:04.000Z",
"inAppPurchases": [
{
"name": "Badoo Premium",
"priceText": "$6.99",
"amount": 6.99,
"currency": "USD",
"planFamily": "Premium",
"durationDays": null,
"usd": 6.99
},
{
"name": "Badoo Premium",
"priceText": "$5.99",
"amount": 5.99,
"currency": "USD",
"planFamily": "Premium",
"durationDays": null,
"usd": 5.99
},
{
"name": "Premium",
"priceText": "$8.99",
"amount": 8.99,
"currency": "USD",
"planFamily": "Premium",
"durationDays": null,
"usd": 8.99
},
{
"name": "Super Powers",
"priceText": "$2.99",
"amount": 2.99,
"currency": "USD",
"planFamily": "SuperPowers",
"durationDays": null,
"usd": 2.99
},
{
"name": "Super Powers",
"priceText": "$2.99",
"amount": 2.99,
"currency": "USD",
"planFamily": "SuperPowers",
"durationDays": null,
"usd": 2.99
},
{
"name": "Super Powers",
"priceText": "$2.99",
"amount": 2.99,
"currency": "USD",
"planFamily": "SuperPowers",
"durationDays": null,
"usd": 2.99
},
{
"name": "Pack of 100 Credits",
"priceText": "$3.99",
"amount": 3.99,
"currency": "USD",
"planFamily": "Credits",
"durationDays": null,
"usd": 3.99
},
{
"name": "pack of 100 Badoo credits",
"priceText": "$1.99",
"amount": 1.99,
"currency": "USD",
"planFamily": "Credits",
"durationDays": null,
"usd": 1.99
},
{
"name": "Super Powers",
"priceText": "$11.99",
"amount": 11.99,
"currency": "USD",
"planFamily": "SuperPowers",
"durationDays": null,
"usd": 11.99
},
{
"name": "7 Days Badoo Premium",
"priceText": "$13.99",
"amount": 13.99,
"currency": "USD",
"planFamily": "Premium",
"durationDays": 7,
"usd": 13.99
}
],
"planSummary": {
"Premium": {
"minAmount": 5.99,
"maxAmount": 13.99,
"currency": "USD",
"minUsd": 5.99,
"maxUsd": 13.99
},
"SuperPowers": {
"minAmount": 2.99,
"maxAmount": 11.99,
"currency": "USD",
"minUsd": 2.99,
"maxUsd": 11.99
},
"Credits": {
"minAmount": 1.99,
"maxAmount": 3.99,
"currency": "USD",
"minUsd": 1.99,
"maxUsd": 3.99
}
},
"fx": {
"source": "ECB",
"date": "2026-09-25",
"rate": 1
},
"error": "",
"sourceUrl": "https://apps.apple.com/us/app/id351331194",
"changes": []
}

App Store, United Kingdom — a second currency, a third Credits-pack size (pack of 550 Badoo credits, 250 Badoo Credits), and the same 7-day Premium duration contrast reproduced on a second storefront:

{
"recordType": "storefront_snapshot",
"brand": "badoo",
"platform": "appstore",
"country": "gb",
"appId": "351331194",
"observedAt": "2026-09-26T15:37:17.843Z",
"status": "ok",
"found": true,
"appTitle": "Badoo: Dating app & Friends App",
"rating": 4.5,
"ratingCount": 40241,
"ratingHistogram": {
"1": 3124,
"2": 635,
"3": 1223,
"4": 5238,
"5": 30021
},
"version": "5.479.0",
"lastUpdated": "2026-09-17T10:22:04.000Z",
"inAppPurchases": [
{
"name": "Super Powers",
"priceText": "£2.29",
"amount": 2.29,
"currency": "GBP",
"planFamily": "SuperPowers",
"durationDays": null,
"usd": 3.034792
},
{
"name": "Badoo Premium",
"priceText": "£6.99",
"amount": 6.99,
"currency": "GBP",
"planFamily": "Premium",
"durationDays": null,
"usd": 9.263405
},
{
"name": "Super Powers",
"priceText": "£2.29",
"amount": 2.29,
"currency": "GBP",
"planFamily": "SuperPowers",
"durationDays": null,
"usd": 3.034792
},
{
"name": "pack of 100 Badoo credits",
"priceText": "£1.99",
"amount": 1.99,
"currency": "GBP",
"planFamily": "Credits",
"durationDays": null,
"usd": 2.637221
},
{
"name": "Badoo Premium",
"priceText": "£4.49",
"amount": 4.49,
"currency": "GBP",
"planFamily": "Premium",
"durationDays": null,
"usd": 5.950313
},
{
"name": "Super Powers",
"priceText": "£8.99",
"amount": 8.99,
"currency": "GBP",
"planFamily": "SuperPowers",
"durationDays": null,
"usd": 11.913879
},
{
"name": "Pack of 100 Credits",
"priceText": "£3.99",
"amount": 3.99,
"currency": "GBP",
"planFamily": "Credits",
"durationDays": null,
"usd": 5.287695
},
{
"name": "pack of 550 Badoo credits",
"priceText": "£7.99",
"amount": 7.99,
"currency": "GBP",
"planFamily": "Credits",
"durationDays": null,
"usd": 10.588642
},
{
"name": "7 Days Badoo Premium",
"priceText": "£9.99",
"amount": 9.99,
"currency": "GBP",
"planFamily": "Premium",
"durationDays": 7,
"usd": 13.239116
},
{
"name": "250 Badoo Credits",
"priceText": "£0.99",
"amount": 0.99,
"currency": "GBP",
"planFamily": "Credits",
"durationDays": null,
"usd": 1.311984
}
],
"planSummary": {
"SuperPowers": {
"minAmount": 2.29,
"maxAmount": 8.99,
"currency": "GBP",
"minUsd": 3.034792,
"maxUsd": 11.913879
},
"Premium": {
"minAmount": 4.49,
"maxAmount": 9.99,
"currency": "GBP",
"minUsd": 5.950313,
"maxUsd": 13.239116
},
"Credits": {
"minAmount": 0.99,
"maxAmount": 7.99,
"currency": "GBP",
"minUsd": 1.311984,
"maxUsd": 10.588642
}
},
"fx": {
"source": "ECB",
"date": "2026-09-25",
"rate": 1.32523679
},
"error": "",
"sourceUrl": "https://apps.apple.com/gb/app/id351331194",
"changes": []
}

Google Play, United States — the same app, this store's genuinely different shape, including the real containsAds: true disclosure and a rating count over 6.6 million:

{
"recordType": "storefront_snapshot",
"brand": "badoo",
"platform": "googleplay",
"country": "us",
"appId": "com.badoo.mobile",
"observedAt": "2026-09-26T15:37:17.514Z",
"status": "ok",
"found": true,
"appTitle": "Badoo Dating App: Meet & Date",
"rating": 4.00678825378418,
"ratingCount": 6653064,
"installs": "100M+",
"lastUpdated": "2026-09-01T00:00:00.000Z",
"containsAds": true,
"iapPriceRange": {
"min": 0.49,
"max": 239.99,
"currency": "USD"
},
"inAppPurchases": [],
"fx": {
"source": "ECB",
"date": "2026-09-25",
"rate": 1
},
"error": "",
"sourceUrl": "https://play.google.com/store/apps/details?id=com.badoo.mobile&hl=en&gl=us",
"changes": []
}

Failure path 1: a malformed country code, rejected before any request

{
"recordType": "storefront_snapshot",
"brand": "badoo",
"platform": "appstore",
"country": "zz",
"status": "invalid_country",
"found": false,
"error": "",
"sourceUrl": null
}

Failure path 2: the source did not answer after retries

A simulated exhausted-retries 429, run through the real code path — captured via the same fetchImpl injection point this line's own tests use (technique described in full in this line's Tinder README): the real runDatingAppIntel entry point and the real Apify ChargingManager, with only the network call itself scripted:

{
"recordType": "storefront_snapshot",
"brand": "badoo",
"platform": "appstore",
"country": "us",
"appId": "351331194",
"observedAt": "2026-09-26T16:06:48.788Z",
"appTitle": null,
"rating": null,
"ratingCount": null,
"ratingHistogram": null,
"installs": null,
"version": null,
"lastUpdated": null,
"releaseNotes": null,
"containsAds": null,
"iapPriceRange": null,
"inAppPurchases": [],
"planSummary": {},
"fx": null,
"fxNote": null,
"sourceUrl": "https://apps.apple.com/us/app/id351331194",
"status": "rate_limited",
"found": false,
"error": "http 429 after retries"
}

Field dictionary

FieldTypeMeaning
recordTypestringAlways "storefront_snapshot".
brandstringAlways "badoo" here.
platformstring"appstore" or "googleplay".
countrystringThe ISO-3166 code requested.
appIdstring351331194 (App Store numeric id) or com.badoo.mobile (Google Play package name).
observedAtstring (ISO 8601)The exact moment this Actor read the page, in UTC.
statusstringok, not_available_in_country, invalid_country, rate_limited or source_error.
foundbooleantrue only for status: "ok".
appTitlestring | nullThe store's own title — "Badoo Dating: Meet New People App" on the App Store, "Badoo Dating App: Meet & Date" on Google Play (genuinely different wording per store, reported exactly as each store prints it).
ratingnumber | nullThe store's own current average rating out of 5 — 4.01 on the US Google Play listing at capture time.
ratingCountnumber | nullTotal ratings behind that average — 6,652,938 on the US Google Play listing at capture time, one of the largest counts this entire line covers.
ratingHistogramobject | nullApp Store only.
installsstring | nullGoogle Play only — "100M+" at capture time.
version / lastUpdated / releaseNotesstring | nullThe listed version, its last-update date, and the "What's new" text in the storefront's own language.
containsAdsboolean | nullGoogle Play only — true for Badoo, a real, disclosed fact (contrast with Bumble and Twinby, both false at their own capture times — this is a genuine per-brand difference, not a parsing artifact).
iapPriceRangeobject | nullGoogle Play only — {min, max, currency} aggregate.
inAppPurchasesarrayApp Store only.
inAppPurchases[].namestringThe plan's own raw name — "Badoo Premium", "7 Days Badoo Premium", "Super Powers", "Pack of 100 Credits", "250 Badoo Credits", and other real capitalization/prefix variants; never rewritten.
inAppPurchases[].planFamilystringSee the plan dictionary table below.
inAppPurchases[].durationDaysnumber | null7 for "7 Days Badoo Premium", parsed from its own explicit duration word. null for every plain "Badoo Premium"/"Premium", every Super Powers entry, and every Credits pack — none of the latter three states a duration, and the numeral in a Credits name (100, 250, 550) is always a QUANTITY, never a duration, regardless of size.
inAppPurchases[].usdnumber | nullConverted via ECB rate when possible; null with fxNote otherwise.
planSummaryobjectPer-planFamily min/max within this row.
fxobject | null{source: "ECB", date, rate} — the exact rate used, or null when nothing needed converting.
fxNotestring | nullSet only when convertToUsd was requested but the ECB has no rate for this row's currency.
errorstringEmpty for a clean "no"; a specific message for rate_limited/source_error.
sourceUrlstring | nullThe exact URL fetched; null only for invalid_country.
changes[]arrayPopulated only with compareWithPreviousRun: true.

Plan dictionary — how planFamily is decided

planFamilyMatched from (case-insensitive substring, longest match wins)
Premium"premium" — covers "Badoo Premium", plain "Premium", and "7 Days Badoo Premium" from one single key, since Badoo's real IAP list has never shown a name that would need a longer, more specific key checked first (unlike Bumble's own premium+/premium pair)
SuperPowers"super powers"
Credits"credits" — covers "Pack of 100 Credits", "pack of 100/550 Badoo credits", "250 Badoo Credits" and every other real prefix/capitalization variant observed live
otheranything not matching the above

Evidence and boundaries

What this Actor reads, exactly. Two public product pages: https://apps.apple.com/{cc}/app/id351331194 and https://play.google.com/store/apps/details?id=com.badoo.mobile&hl=en&gl={cc}.

robots.txt, checked, not assumed. apps.apple.com disallows /api/*, /v1/*, /WebObjects/*, /includes/*, */search?*. play.google.com disallows /store/getreviews, /store/search, /store/xhr, /store/apps/datasafety*. This Actor's own fetched paths are not among either domain's disallowed set.

Credits-pack numerals are quantities, demonstrated with real contrasting evidence, not just asserted. This is the single most important field-level honesty point for this brand. Four real, live-captured Credits-pack names — "Pack of 100 Credits", "pack of 100 Badoo credits", "pack of 550 Badoo credits", "250 Badoo Credits" — all carry durationDays: null in this README's own Output section, while the real "7 Days Badoo Premium" name, captured in the very same run, carries durationDays: 7. The rule is not "small numbers are quantities, large numbers might be durations" — it is purely lexical: this Actor's duration parser fires only on an explicit day/week/month/year unit word appearing in the plan's own name, and 100, 250 and 550 never appear next to such a word in any real Badoo Credits name captured so far. A number by itself, however large, never triggers a duration guess.

429 is a measured risk, not a guess. From this line's own test infrastructure's IP range, hitting Apple's App Store every 8 seconds produced 5 real 200 responses and 7 real 429s out of 12 consecutive requests; the same IP paced at 30 seconds with a 45-second retry produced 5 real 200s out of 5. This Actor's own fetch layer caps concurrent requests toward Apple at 2 per run and retries with backoff before reporting rate_limited.

What the App Store's own feed does NOT publish. No age rating, no install count (Google Play's own disclosure), and no duration for a plan whose own name doesn't state one.

What this Actor does NOT do, and will not be extended to do. No account, no login, no profile/photo/message/match data of any real Badoo user, no review-feed reads (both domains' review endpoints are robots.txt-disallowed and never fetched), no store search (every app identifier is hard-coded per brand), no private API of Bumble Inc.'s, Apple's or Google's. Permanent design boundaries, not missing features.

Why the two different App Store title spellings ("Meet New People" vs. "Meet & Date") are both correct. Apple's own App Store page and Google's own Google Play page carry genuinely different title text for the same app — this Actor reports each store's title exactly as that store prints it, rather than normalizing them to look consistent, because doing so would mean silently editing what the source itself actually says on its own page.

Google Play's rating is reported at full floating-point precision. This Actor passes the number through exactly as the page's own structured data states it, unrounded, rather than deciding on your behalf how many decimal places matter for your use case.

Decision routing

Use this Actor when you specifically want Badoo's own subscription and Credits-pack prices, normalized into a stable planFamily, with an app-title/rating/version read attached, from the App Store and Google Play as the two sources.

A generic App Store/Google Play field-extraction Actor won't tell you which Credits-pack numeral is a quantity and which plan's numeral is a duration — it will hand you raw text with no planFamily or durationDays opinion at all. This Actor costs more per storefront specifically because it already resolved that ambiguity, against real captured evidence, so you don't have to write and maintain that parsing logic yourself.

Use one of this Actor's own siblings instead of Badoo when the brand you care about is different: the same engine also ships as separate Actors for Tinder, Twinby (adds RuStore), Bumble and Hinge. Badoo and Bumble share Bumble Inc. as their own parent company but have entirely separate plan dictionaries with zero naming overlap — running this Actor tells you nothing about Bumble's own pricing, and vice versa; if you need both brands, run both Actors and merge the two datasets yourself.

Use this Actor's compareWithPreviousRun feature rather than a fresh manual comparison when the question is "did anything change since last time" — the diff logic already exists, is billed the same way as a fresh read, and isn't vulnerable to the easy mistake of comparing two exports taken under different convertToUsd settings.

Let compareWithPreviousRun do the Credits-pack-size tracking for you rather than comparing two manual exports — a new pack size (say a 1000-Credits bundle Badoo hasn't listed before) shows up directly as a new entry in changes[], keyed correctly by this Actor's own saved snapshot per watchId, without you having to notice the new name string buried in a full export by eye.

Do not use this Actor for anything about real Badoo users — profiles, matches, messages. No configuration will ever do that; it is a permanent boundary.

Commercial playbooks

Brand-by-brand pricing comparison within Bumble Inc.'s own portfolio. An analyst covering Bumble Inc. runs this Actor alongside this line's own Bumble Actor, on the same schedule and the same country list, to build a direct, dated comparison of how the same parent company prices its two major brands differently in the same market — a comparison Bumble Inc.'s own aggregate revenue disclosure does not provide at this granularity.

Competitive benchmarking against the largest install-base competitor in a given market. A product team at Tinder, Bumble, Hinge or Twinby pulls Badoo's current Premium and Super Powers pricing before setting their own, specifically because Badoo's 100M+ install bucket and 6.6-million-plus rating count make it one of the most-established competitors to benchmark against in most markets this line covers.

ASO agency monthly client report. Badoo's App Store and Google Play numbers, including its real containsAds: true disclosure, slot into the same monthly competitive-pricing report structure this line's other Actors describe.

Credits-pack pricing-per-unit analysis. A pricing researcher computes an implied-price-per-credit figure by dividing each Credits pack's own price by the quantity stated in its own name (100, 250, 550), using this Actor's raw name/amount/currency fields as the input — this Actor does not compute a price-per-unit figure itself, since doing so would require parsing the quantity out of free text as a fact rather than reporting the plan's own stated price, but the raw fields needed for that computation are all present.

Currency and purchasing-power research. A researcher uses Badoo Premium's real per-country price ladder, alongside this line's other four brands, as a clean comparable input into a broader digital-subscription pricing study.

Pre-earnings sanity check for a Bumble Inc. IR or comms team. Before a filing references Badoo's own pricing or growth, an IR or comms team runs this Actor across the brand's key disclosed markets to confirm what is actually live on each storefront, independent of whatever the internal pricing team's own change log says should have shipped.

Portfolio-wide review-momentum tracking. An analyst comparing Bumble Inc.'s two brands runs this Actor's ratingCount field alongside this line's own Bumble Actor output on the same schedule, as a rough proxy for which brand is generating more review momentum in a given market at a given time, without needing a separate review-scraping tool that would touch either store's disallowed review feed.

Integration recipes

Schedule it (Apify Console). Open the Schedules tab, create a cron expression, attach the input you want repeated, and every scheduled run lands in this Actor's own dataset history.

Call it from the REST API.

curl -X POST "https://api.apify.com/v2/acts/zinin~badoo-app-intel/runs?token=$APIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"countries": ["us", "gb"], "platforms": ["appstore", "googleplay"], "convertToUsd": true}'

Call it from Node.js or Python via Apify's own SDK.

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const run = await client.actor('zinin/badoo-app-intel').call({
countries: ['us', 'gb'],
platforms: ['appstore', 'googleplay'],
convertToUsd: true,
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();

The Python client (apify-client on PyPI) mirrors the same call shape: client.actor('zinin/badoo-app-intel').call(run_input={...}).

Wire it to a webhook. Attach a webhook fired on ACTOR.RUN.SUCCEEDED to your own endpoint; check OUTPUT.partial in the payload since a run can finish SUCCEEDED while one storefront came back rate_limited.

Call it as a tool from an LLM agent, via Apify's MCP server (https://mcp.apify.com) — once published, callable by name with the same input shape as any other integration path here.

Export straight to Google Sheets. Use the Dataset tab's "Export data" action and choose Google Sheets, or a Sheets-sync automation watching for ACTOR.RUN.SUCCEEDED, to keep a live spreadsheet of Badoo's Premium and Credits pricing updated on your own schedule.

Plain CSV/Excel for a one-off analysis. The Dataset tab's Export button produces a ready-to-open CSV or Excel file of exactly the rows in that run.

Operating guide

Reading a partial run. Check OUTPUT.partial first, not the run's own top-level status — a run can finish successfully while some storefronts came back rate_limited.

When to retry a rate-limited storefront. A single rate_limited row is usually transient at this Actor's own pacing (see Evidence and boundaries); a storefront that stays rate_limited across several attempts over an hour or more is worth treating as a real, ongoing block rather than transient noise.

Choosing a watchId strategy. One watchId per logical tracking list — a "BMBL-portfolio pricing" watch covering both Badoo and Bumble and a "Credits-pack unit pricing" watch should use different watchIds so their changes[] histories never mix.

maxStorefronts on a large country list. Combinations beyond the cap are dropped before any request is made and reported in one free status: "truncated" row naming exactly what was skipped. Raise maxStorefronts (up to 120) for a genuinely large single run, or split a long country list across a few scheduled runs to keep OUTPUT.deadlineHit false (the soft 280-second budget on the prefill-sized path).

Comparing US and UK pricing side by side. Both currencies convert cleanly to USD via the ECB rate when convertToUsd is on, so a direct usd field comparison across the two rows is safe without extra work. This is specifically NOT true for every brand in this line — Twinby's RUB rows never get a usd figure — so confirm which currencies are actually involved before assuming a cross-country USD comparison generalizes to a brand you haven't checked.

Reading containsAds across a country list. This field reflects Google Play's own disclosure for THIS app, and this Actor has observed it as a consistent true for Badoo across every country checked so far — treat a sudden false in a future run as worth a second look (a genuine policy change) rather than assuming it's a parsing fluke.

Computing a price-per-credit figure downstream. Parse the leading or trailing numeral out of a Credits entry's own name field yourself if you need a per-unit price — this Actor deliberately does not do this parsing itself (see Commercial playbooks), so your own downstream logic should treat name as the source of the quantity and amount/currency as the source of the price, joined by you, not by this Actor.

FAQ

Why is durationDays null for a "Pack of 100 Credits" but not for "7 Days Badoo Premium"? Because the second name states its own duration in words ("Days") and the first doesn't — this Actor's duration parser only ever fires on an explicit unit word, never on a bare number regardless of size. 100 credits is a quantity; "7 Days" is a duration. See Evidence and boundaries for the full real-data demonstration.

Does Badoo share any plan names with Bumble, since both are owned by Bumble Inc.? No — based on every live capture this line has taken of both brands, Badoo's own naming (Premium, Super Powers, Credits) and Bumble's own naming (Premium/Premium+, Boost, BumbleCoins) do not overlap except for the word "Premium" itself, which each brand's own dictionary handles independently since they're two separate Actors reading two separate apps' own separate pages.

Why does Google Play show containsAds: true for Badoo but false for Bumble and Twinby? Because that is genuinely what each app's own Google Play listing discloses — this is a real, disclosed difference between the three apps, not an inconsistency in how this Actor reads the field. This Actor reports what each store's page actually says, per app, with no assumption that similar apps disclose the same thing.

Can I compute a price-per-credit figure directly from this Actor's output? Not automatically — this Actor reports the plan's own stated name, amount and currency, but does not itself parse the quantity out of the name as a numeric fact, since doing so would mean treating free text as a structured field the source itself doesn't explicitly provide that way. See Commercial playbooks and Operating guide for how to compute it yourself from the raw fields.

Does this Actor read anything about real Badoo users? No, and it never will — see Evidence and boundaries for the permanent, complete list of what it does not do.

If the US App Store storefront gets rate-limited, do I still get the Google Play row for the same country? Yes — platform and country combinations are each fetched independently, so a rate_limited App Store result never affects the Google Play row for the same country in the same run; you'd see one free row and one normal, billed row side by side.

A Credits pack I saw on the page last week isn't in this run's output — did this Actor miss it? Possibly not a miss at all — Apple and Google both rotate which Credits-pack sizes a given storefront lists from time to time, and this Actor reports exactly what's live on the page at the moment of the read. If a pack genuinely disappeared, compareWithPreviousRun would show it in changes[] as a removed plan; if this Actor's own parser is skipping a real, still-listed entry, that's a bug worth reporting on this Actor's own page.

Is a 550-Credits pack better value per credit than a 100-Credits pack? This Actor doesn't compute that for you (see Operating guide for why), but the raw fields needed to compute it yourself are all present in inAppPurchases[] — divide amount by the quantity stated in name for each pack, in the same currency, and compare.

Why does this brand's plan dictionary use one premium key where Bumble's needs two (premium+ and premium)? Because Badoo's own real, live-captured IAP list has never shown a tier name that would collide with the plain premium substring the way Bumble's Premium+ does — there's no dictionary key ordering risk to guard against here, so the dictionary stays simpler. This is a genuine per-brand difference in how each app's own feed names its own tiers, not an inconsistency in how the two Actors are built.

Does a rate_limited row on Badoo behave any differently from the same status on Bumble, Tinder, Hinge or Twinby? No — rate_limited, like every other status in this line's shared field dictionary, means the same thing and is billed the same way (free, always) across every brand. Only the appId/sourceUrl fields differ, since those are brand-specific; the status semantics themselves are shared, generic code in this line's own lib/, not reimplemented per brand.

Can I run this Actor and this line's Bumble Actor with the same watchId to get one combined portfolio history? You can pass the same string, but each Actor writes to its OWN saved snapshot store, keyed by that Actor's own default key-value store — the diff logic never mixes data between two separate Actors even if you happen to reuse the same watchId label across both. If you want a single combined view, merge the two datasets on your own side after both runs finish; this Actor does not do that merging for you.

Why does this README cite a specific rating count (6,652,938) instead of just saying "millions"? Because the exact figure is what this Actor's own real captured row actually contains, and this README's own standard is to cite real captured numbers rather than rounding them into a vaguer, less falsifiable claim. The number will be different the next time this Actor runs; the field itself, and the fact that this Actor reports it exactly as the source states it, will not change.

Sources and rights

Every fact in this Actor's output comes from one of two public sources: Apple's own App Store product page at apps.apple.com/{cc}/app/id351331194, and Google's own Google Play product page at play.google.com/store/apps/details?id=com.badoo.mobile. Both are pages any visitor can open with no account; this Actor respects both domains' published robots.txt and calls no private, undocumented or authenticated API belonging to Apple, Google or Bumble Inc.

Currency conversion, when requested, uses the European Central Bank's own published daily reference rate feed — public data, no key or account required.

This Actor collects no personal data of any kind and has no code path that reads, infers or stores anything about a real Badoo user. "Badoo" and its plan names (Premium, Super Powers, Credits) are Bumble Inc.'s own trademarks and terminology, reported here only because they are the storefront's own public labels for its own public prices — this Actor is independent and not affiliated with, endorsed by, or operated on behalf of Bumble Inc., Apple or Google.

Found a wrong result, or need a case this README doesn't cover? Open an issue on this Actor's own page. This Actor's own source code respects the same public-data-only boundary this page describes throughout: every field it can produce traces back to one of the two URLs above, every currency conversion traces back to the ECB's own published feed, and no field is ever populated from an assumption or a value carried over from a previous run when the current run's own source didn't actually provide it. That is the standard this README holds itself to, and the standard every other Actor in this same five-brand line is held to as well — whether the brand is Match Group's Tinder and Hinge, Bumble Inc.'s Bumble and this Actor's own Badoo, or the independently-operated Twinby.


Built by zinin. Questions? Telegram @timzinin.