CAMPFIRE Funding-Risk Classifier

If you're a backer, journalist, or analyst trying to tell which CAMPFIRE crowdfunding projects carry real funding risk — not just which ones look popular — this Actor reads each project's own funding stats and flags the risk CAMPFIRE's UI doesn't spell out: whether an under-target project is All-In (money goes to the creator regardless, so the real risk is under-resourced delivery) or All-or-Nothing (money is only collected if the goal is hit, so the real risk is the project never happening at all).

What you get, per project:

• Full funding data — goal, amount raised, achievement rate, funding type, campaign dates, reward-tier price range, category — as clean structured JSON, straight from CAMPFIRE's own structured data (no fragile CSS-class scraping)
• A funding-risk flag (fundingRisk) computed from funding type + achievement rate + days remaining — the one signal none of the ~20 existing Kickstarter-scraper Actors provide, since Kickstarter itself only has one funding model and doesn't need this distinction
• Two ways in — classify specific project URLs, or discover and classify CAMPFIRE's most recently listed projects automatically via its own sitemap

{
  "title": "西尾市を住みよい街にするために!家庭訪問型子育て支援ホームスタートを立ち上げたい",
  "category": "まちづくり・地域活性化",
  "fundingGoalYen": 500000,
  "amountRaisedYen": 488500,
  "achievementRatePercent": 97.7,
  "fundingType": "All-In",
  "fundingRisk": {
    "riskLevel": "all-in-underfunded",
    "riskLabel": "実行時資金不足の可能性",
    "note": "All-In方式のため目標未達でも支援金は実行者に渡り、プロジェクトは実行されます。現在の達成率は97.7%のため、当初想定した予算どおりに実行・リターン提供ができるかは実行者の資金繰り次第です。"
  }
}

(Full record — description, sponsor, reward-price range, campaign dates — is in the Output section below.)

Pay-per-event pricing, cost-measured on a real production-scale run — see "Pricing" below. Input parameters and the full funding-risk logic are further down this page.

⚠️ Disclaimer (please read)

• This Actor automatically retrieves information that is publicly available on CAMPFIRE (camp-fire.jp). You are responsible for how you retrieve and use this data.
• The site owner's Terms of Use, robots.txt, or access blocking could change without notice, which could stop this Actor from working or change its output unexpectedly.
• fundingRisk is a heuristic estimate derived from public funding-type/achievement-rate/schedule data, not an official CAMPFIRE classification and not a guarantee. It does not assess the project owner's actual finances, creditworthiness, or ability to deliver. Always verify a project directly on CAMPFIRE before backing it or making any decision based on this data.

Facts confirmed during pre-build research (as of August 17, 2026)

• Terms of Use (camp-fire.jp/term, read in full — 38 articles): unlike Makuake, CAMPFIRE's ToS has no blanket "no commercial use" clause. The closest relevant provisions are Article 27-1-(10), which restricts the activity-report/messaging features (not data in general) to in-service purposes, and Article 34-3, which permits reposting a project's URL/title/summary/images for promoting the project but requires CAMPFIRE's prior consent for posting to other print/web media for any other purpose. Neither is the site-wide commercial-use restriction our SUUMO/PR TIMES Actors have to disclaim.
• robots.txt: User-agent: *, disallows /mypage, /projects/*/backers/ (the backer list per project), /projects/*/preview, /inquiries, and a few other account/internal paths. Project detail pages (/projects/{id}/view) are not disallowed. No AI-crawler-specific rules (no GPTBot/Google-Extended block, unlike Makuake — see "Known limitations").
• CDN / bot protection: fronted by CloudFront + nginx. Plain curl requests (bare curl UA and a browser UA) to the top page and to a real project detail page both returned normal HTTP 200 with no Cloudflare-style markers (no cf-ray, no JS challenge). Only verified with single, low-frequency requests — sustained high-volume behavior has not been tested. Note: CAMPFIRE's search/listing page (/projects/search) is a client-rendered SvelteKit SPA with no project data in its initial HTML — this Actor never uses it, relying on the sitemap and direct project URLs instead (see "What does this Actor do?").

PII design

This Actor never fetches CAMPFIRE's backer-list or communication/comment pages (/projects/*/backers/) — CAMPFIRE's own robots.txt disallows exactly that path, which this Actor treats as a signal that backer-level personal data concentrates there, not just a crawl courtesy. Only project detail pages and the public sitemap are ever requested.

That still leaves two fields that can carry an individual's identity, since a project's owner (sponsorName) is frequently a personal account handle rather than a company name for individual creators (confirmed during research: real examples include handles like Yutaro_asobi, nishio_hazu, hitohineri_buyshop_jp) — and in principle a full real name could appear here or in the free-text title/description fields. This Actor applies the same regex-based safety net used by our BOOTH and carsensor Actors (src/privacyFilter.js) to title, description, and sponsorName right before output: each is scanned for email-address/phone-number-like patterns and contact labels (e.g. "担当:"); any match nulls out that field, and the detection is recorded in personalInfoRedactions.

No match was found in the real projects sampled during pre-build research (see the sample output below — personalInfoRedactions: []), but this is a safety net for cases the sample didn't happen to cover, not a guarantee the underlying pages never contain such text.

What does this Actor do?

• byUrl mode: classifies specific project(s) given in projectUrls (full URL or a bare numeric project ID).
• bySitemap mode: discovers recently listed projects via CAMPFIRE's own project sitemap (camp-fire.jp/sitemap.xml → sitemap/projects.N.xml), newest first, and classifies those. This exists because CAMPFIRE's own search/listing page is a client-rendered SPA with no project data in its initial HTML (see "Facts confirmed" above) — the sitemap is the only server-rendered way to discover projects in bulk.
• For each project, extracts (from the detail page's own schema.org JSON-LD — not CSS-class scraping): funding goal, amount raised, funding type (All-In / All-or-Nothing), campaign start/end dates, category (from the breadcrumb), and reward-tier price range (low/high price, tier count).
• Computes achievementRatePercent, daysRemaining, isActive, and the fundingRisk assessment — see "Funding-risk logic" below.
• onlyRiskFlagged limits output and billing to projects whose fundingRisk.riskLevel is anything other than "funded"/"unknown".
• An optional category filter narrows output to a matching category label — see "Known limitations" for why this doesn't reduce the number of pages fetched.

Who is this for?

Roughly 20 Kickstarter-scraping Actors already exist on the Apify Store, and essentially all of them are raw-data feeds: funding goal, pledged amount, backers, deadline, creator, category. None of them compute a derived risk signal — which makes sense, since Kickstarter only has one funding model (all-or-nothing) and doesn't need this distinction. Japanese crowdfunding platforms like CAMPFIRE run both All-In and All-or-Nothing campaigns side by side, so "is this project actually at risk, and what kind of risk" is a real question a raw funding-stats feed doesn't answer on its own. This Actor's differentiation is turning that already-public funding-type + achievement-rate combination into a structured, ready-to-use risk flag (same stack as our BOOTH, SUUMO, PR TIMES, Rakuten Travel, and carsensor Actors: JavaScript ESM, Apify SDK, Pay-per-event pricing).

Input

Parameter	Type	Default	Description
mode	string	bySitemap	bySitemap (discover recent projects) / byUrl (specific project URL(s))
projectUrls	array	[]	For byUrl: project URL(s), e.g. "https://camp-fire.jp/projects/643676/view" (a bare numeric ID is also accepted)
category	string	"" (empty)	Optional: only output projects whose category label matches this text (e.g. "チャレンジ"). Matched after fetching each project's detail page — see "Known limitations"
onlyRiskFlagged	boolean	false	When on, only outputs and charges for projects with a non-funded/unknown fundingRisk
maxItems	integer	20	Cap on the number of projects output/charged (max 200)
maxDetailFetches	integer	60	Safety cap on how many project detail pages are actually fetched (max 500)
requestDelayMs	integer	1500	Delay between requests in ms. Cannot be set below 1000ms for safety

Output

The following is actual output from a real run of this Actor against the live site (August 17, 2026, project 643676 via byUrl mode — a since-ended, fully-funded campaign, kept as the example because its reward-tier and category data give the fullest record shape).

{
  "sourceUrl": "https://camp-fire.jp/projects/643676/view",
  "projectId": "643676",
  "title": "自転車で日本一周の旅をして、子どもと同世代に挑戦する姿を見せつけたい！！",
  "description": "『２３歳の二人が仕事を辞めて自転車で日本一周に挑戦』する冒険物語を、YouTubeやライブ配信して届けたい！！\n子どもや同世代に！そしてより多くの人に届けたいです！",
  "image": "https://static.camp-fire.jp/uploads/project_version/image/987661/8701ab52-c65b-4175-97ac-0294fe017329.jpeg?auto=format&fit=max&ref=projects_overview",
  "sponsorName": "Yutaro_asobi",
  "category": "チャレンジ",
  "categorySlug": "challenge",
  "fundingGoalYen": 600000,
  "amountRaisedYen": 1400777,
  "fundingType": "All-In",
  "startDate": "2022-12-16",
  "endDate": "2023-02-02",
  "achievementRatePercent": 233.5,
  "daysRemaining": -1292,
  "isActive": false,
  "rewards": { "lowPriceYen": 1000, "highPriceYen": 100000, "offerCount": 16 },
  "fundingRisk": {
    "riskLevel": "funded",
    "riskLabel": "目標達成",
    "note": "目標金額の233.5%を集めています。 (All-In方式のため目標未達でも実行はされますが、今回は達成済みです。)"
  },
  "disclaimer": "CAMPFIRE上の公開情報を基に自動生成した参考データです。...",
  "scrapedAt": "2026-08-17T06:35:47.208Z",
  "personalInfoRedactions": []
}

See the sample JSON at the top of this README for a real all-in-underfunded example (project 604712, 97.7% funded, All-In, campaign already ended) — the case this Actor's risk flag exists to surface.

Funding-risk logic

CAMPFIRE runs projects under two official funding types (fundingType, confirmed by sampling both old and recent real projects), and this Actor's fundingRisk is derived entirely from that field plus achievementRatePercent and campaign timing — no ML, no external data:

1. funded: achievementRatePercent >= 100, regardless of funding type. Lowest risk — the project reached its own stated goal.
2. all-in-underfunded: fundingType: "All-In" and achievementRatePercent < 100. All-In means the creator receives whatever was raised even if short of the goal, and the project proceeds regardless — so the risk isn't "will this happen," it's "was this actually resourced at the level the creator planned for."
3. all-or-nothing-in-progress: fundingType: "All-or-Nothing", achievementRatePercent < 100, campaign still active. No money has changed hands yet; the risk is the project failing to reach its goal and never happening, not a delivery risk.
4. all-or-nothing-failed: same as above but the campaign's endDate has passed. The project is presumed to not have been funded.
5. unknown: fundingGoalYen or fundingType couldn't be read from the page.

Known limitation: this is a rules-based flag on public numbers, not an assessment of the creator's actual finances, track record, or ability to deliver — two all-in-underfunded projects at the same achievement rate can have very different real-world risk. Treat it as a screening signal, not a verdict.

Pricing

Event	Price	Trigger
Actor Start (apify-actor-start)	$0.00005	Once per run (Apify's standard synthetic event)
Project classified (project-classified)	$0.015	Per project output, with full funding stats and reward-tier data
Funding risk flagged (funding-risk-flagged)	$0.045	Charged in addition to project-classified when fundingRisk.riskLevel is not funded/unknown

A flagged project therefore costs $0.06 total; an unflagged one costs $0.015.

How the price was set

This Actor was deployed and cost-measured on the Apify platform (August 17, 2026) with a production-scale bySitemap run — 25 projects output, discovered via CAMPFIRE's own sitemap, no byUrl/pre-picked input:

Metric	Measured
Run time	85.7s
Compute units	0.0238 CU
Peak memory	149MB (of 1024MB allocated)
Total infra cost (usageTotalUsd)	$0.0049475 for 25 items
Infra cost per item	≈$0.0002 (96% compute-bound, same profile as our carsensor Actor's $0.00012/item)
Risk-flag rate in this run	22/25 (88%) — 19 all-in-underfunded, 3 all-or-nothing-in-progress

Against that ≈$0.0002/item real cost, project-classified alone already carries a ~75x margin, and the full $0.06 flagged-item price carries a ~300x margin — comfortably past the 100x+ floor we hold every Actor in this series to.

The funding-risk-flagged bonus is priced closer to PR TIMES's sales-timing-signal-detected ($0.045, 3x its base tier) than to carsensor's value-score-computed ($0.065, ~4.3x its base tier), even though all three are the same shape of feature — a derived decision signal computed from data already fetched for the base event, at essentially zero marginal infra cost. The reason is the measured risk-flag rate: in the production-scale run above, 88% of sitemap-discovered projects were risk-flagged. carsensor's valueScore and PR TIMES's sales-timing-signal are both comparatively rare, selective signals (most listings/releases don't trigger them), which is closer to what justifies a large multiplier as a "rare, high-value hit." Here, the risk flag is closer to the norm than the exception for freshly-discovered projects, so pricing it at carsensor's multiplier would functionally make $0.08/item the everyday price rather than a premium for a selective insight — the PR TIMES-tier multiplier keeps the two-tier pricing meaningful while still pricing the signal well above a bare classification.

Load management

There's a default 1500ms delay between every HTTP request this Actor makes (sitemap fetches and project detail pages share one pacing clock in campfireClient.js). Configurable via requestDelayMs, but it cannot be set below 1000ms for safety.

FAQ

Why does category filtering still consume my maxDetailFetches budget even when nothing matches? CAMPFIRE's public sitemap has no category information — only a project's own detail page (via its breadcrumb JSON-LD) does. So bySitemap mode has to fetch a project before it can tell whether it matches your category filter. Non-matching projects still count against maxDetailFetches (but are not output or charged).

Why is fundingRisk.riskLevel sometimes "unknown"? Either fundingGoalYen or fundingType couldn't be read from the project's structured data — this shouldn't normally happen for a live CAMPFIRE project page, but is handled defensively rather than crashing the run.

Does this cover Makuake too? Not in this version — see "Known limitations."

What if CAMPFIRE changes its page layout? The selectors and URL patterns in src/campfireClient.js were verified against real CAMPFIRE response HTML (sitemap XML, project detail pages' schema.org JSON-LD) as of August 17, 2026. CAMPFIRE's markup may change over time; if this stops working, run npm run test-connectivity to inspect the actual response and adjust accordingly.

Why does the risk-flag bonus get charged on almost every project? In production-scale test runs, 88-100% of projects discovered via bySitemap came back risk-flagged (see "How the price was set" under "Pricing"). That's a real, measured property of which projects the sitemap surfaces — recently listed/still-active campaigns skew toward under-target All-In projects — not a pricing trick. See "Known limitations" for the caveat that this rate isn't yet confirmed as a durable, platform- wide baseline.

Known limitations

• Makuake is not covered in this version. Pre-build research found Makuake's robots.txt explicitly blocks GPTBot, Google-Extended, and Amazonbot (each Disallow: /) — a deliberate AI/bulk-crawler- hostile stance CAMPFIRE's robots.txt doesn't share. Combined with Makuake's ToS having a blanket commercial-use restriction that CAMPFIRE's doesn't (see "Facts confirmed" above), this version scopes to CAMPFIRE only; Makuake support is a possible future extension, not a current gap in this Actor's stated purpose.
• The category filter is post-fetch, not pre-fetch (see FAQ) — it narrows output, not cost. Don't rely on it to control run cost; use maxDetailFetches for that.
• bySitemap's "most recent first" ordering is a heuristic, not a documented CAMPFIRE guarantee. It assumes project IDs are assigned in registration order and sitemap files append in ID order — true in every sample checked during research, but not something CAMPFIRE commits to.
• A project owner's 特定商取引法 (Specified Commercial Transactions Act) disclosure page — which by Japanese law must exist somewhere reachable from the project/profile page for a "販売業者"-status owner, and would contain a real name/address — was not located during pre-build research and is not fetched by this Actor (deliberately out of scope, not silently missed).
• sponsorName is usually an account handle, not confirmed to always be safe. Every individual-creator example sampled during research was a handle (e.g. Yutaro_asobi), not a bare real name — but this wasn't checked against a large enough sample to rule out real names appearing here, which is exactly why the privacy safety net (see "PII design") applies to this field too, not just to free-text fields.
• The 88% risk-flag rate cited in "Pricing" is a single-sample measurement (25 projects, one bySitemap run on August 17, 2026), not a verified long-run baseline. It's plausible that CAMPFIRE's sitemap systematically surfaces newer/still-active campaigns, which would skew toward under-target All-In projects more than a random sample of all CAMPFIRE projects ever listed would. Whether 88% (or something close to it) holds up as a durable, platform-wide rate hasn't been checked across multiple runs, time periods, or categories. If it does hold up, the practical implication is that $0.06/flagged item is, in effect, the standard price most users will pay per output row, not an occasional premium on top of a $0.015 baseline — worth knowing going in rather than discovering after the fact.

Possible future extensions (not implemented in v0.1)

• Makuake as a supplementary data source, once its ToS/robots.txt posture is weighed against the value of a cross-platform view — see "Known limitations."
• Category-level trend aggregation: since funding stats are structured and bulk-crawlable via the sitemap, an aggregate view (achievement-rate distribution by category, funding velocity) is feasible without per-page fragility — not implemented in v0.1 to keep scope manageable.
• Pre-fetch category filtering, if CAMPFIRE exposes any server-rendered, category-filterable listing endpoint that wasn't found during this Actor's research.