Japan Buying Intent Signals — RFI & RFQ

Find Japanese public-sector requests for information and quotations with the buyer, purchase subject, product category, response deadline and official source. Use the output to decide which opportunities fit your equipment or services, then review the official requirements before responding.

Current coverage is deliberately limited: Forestry Agency quotation notices indexed by the official 官公需情報ポータル API, and Osaka City's Digital Administration Bureau RFI announcements. This is not a nationwide tender database or a private-company contact list. No OpenAI or other AI API key is needed.

What you get

• request_for_quotation: an official request for prices for goods or services, including open-counter procurement.
• request_for_information: an early information-gathering notice. It is not a purchase commitment, awarded budget, order or guaranteed sales lead.
• The buyer, subject, source date, deadline, prefecture, category, urgency, rule evidence and license attribution in every result.
• Persistent suppression of unchanged results across runs, plus stable IDs for your CRM or workflow.

Useful for facilities/fire-safety vendors, vehicle-service suppliers and software/data-platform vendors watching the supported sources. Procurement qualifications and submission procedures still apply.

Start with a live check

The Store form opens with a maximum 10-result snapshot preview (onlyChanges: false). Each preview run is billable, including unchanged records. This lets you inspect the current output without consuming monitoring history.

For recurring monitoring, turn on Only new or changed signals. API calls without this property default to change monitoring. The following monitoring input is ready to use:

{
  "sources": ["forestry-quotes", "osaka-rfi"],
  "lookbackDays": 30,
  "maxResults": 50,
  "onlyChanges": true,
  "monitorKey": "default"
}

For a focused feed, add "keywords": ["消防", "修繕"] or full Japanese prefecture names such as "prefectures": ["北海道"]. Keywords are literal, case-normalized OR matches in the purchase subject/title or English category. They are not arbitrary source queries.

The first run returns current matching opportunities. Subsequent runs with the same monitor name and filters return new or materially changed notices only. Zero new results can be a normal successful outcome. Check the SUMMARY record to distinguish no matches from an upstream failure or a source/result cap.

Example captured on 18 September 2026 (Japan time). This is a dated snapshot, not a promise that the opportunity is still open. Full output also includes stable IDs, change type, deadline evidence and license links.

{
  "companyName": "大阪市デジタル統括室",
  "organizationType": "local_government",
  "signalType": "request_for_information",
  "expectedPurchase": "大阪市データ利活用環境",
  "productCategory": "data_analytics",
  "signalDate": "2026-09-02",
  "urgency": "medium",
  "sourceUrl": "https://www.city.osaka.lg.jp/ictsenryakushitsu/page/0000685853.html",
  "sourceTitle": "大阪市データ利活用環境に係る情報提供依頼(RFI)を実施します",
  "prefecture": "大阪府",
  "confidence": 0.95,
  "deadline": "2026-09-30",
  "purchaseBasis": "information_request_not_purchase_commitment",
  "license": "CC-BY-4.0",
  "attribution": "Created by Japan Signal Lab by processing 大阪市デジタル統括室's notice (https://www.city.osaka.lg.jp/ictsenryakushitsu/page/0000685853.html); CC-BY-4.0."
}

Three complete source-attributed sample records are included in the implementation package under examples/output.sample.json.

Output fields

Field	Meaning
companyName	Official issuing organization, including public-sector buyers; the local unit may also appear in sourceTitle.
organizationType	government_agency or local_government.
signalType	request_for_information or request_for_quotation.
expectedPurchase	Purchase subject taken from the notice title; no invented budget or purchase stage.
productCategory	Deterministic subject dictionary category. Generic goods remain other.
signalDate, signalDateKind	Source page date, or official API publication/index date. Indexing does not prove that an opportunity is newly announced.
deadline, deadlineEvidence	Unambiguous response/quotation date and its supporting phrase. Question deadlines and delivery dates are not response deadlines.
urgency, status	Date-based triage in Japan time; due_today requires checking the exact closing time at source.
sourceUrl, sourceTitle, sourcePageUrl	Official notice and discovery provenance.
prefecture	Source-reported area, which is not always the delivery/work location. Unknown is null.
confidence, confidenceReasons	Evidence score for classification/extraction, not purchase probability, buyer creditworthiness or chance of winning.
eventId, recordId, changeType	Stable update/deduplication identifiers and new, updated or snapshot.
license, licenseUrl, sourceTermsUrl, attribution	Underlying source license and processing attribution. Preserve these when sharing/exporting.

Evidence score: 0.60 for a recognized official notice stage, +0.20 for a subject dictionary match, +0.10 for an unambiguous deadline, +0.05 for directly fetched Osaka HTML. Generic subjects can score 0.70 with a clear deadline. This arithmetic is a transparent heuristic, not a statistically calibrated model.

Urgency is high at 0–7 days to the response date, medium at 8–21, low after 21, unknown without a date, and closed after the date or on explicit cancellation. Deadlines have date precision, not time precision. Expired/cancelled and missing/conflicting-deadline notices are excluded by default. Advanced inputs can include them for research.

Recurring monitoring

1. Enable Only new or changed signals, then save the desired input as an Apify Task.
2. Schedule it daily, for example at 09:00 in the Asia/Tokyo time zone. The sources do not require minute-by-minute polling.
3. Keep onlyChanges: true and the same monitorKey. Filter changes automatically use separate history; changing only the lookback or result cap retains history.
4. Read the Dataset through the Apify API or your normal Make/Zapier/webhook integration. Upsert by eventId. Configure notifications in your own integration; this Actor does not send messages or contact prospects.

Named storage belongs to the account running the Actor. History is retained for 365 days, capped at 20,000 delivered versions. A new monitor name starts fresh. onlyChanges: false returns a snapshot without consuming change history. Previously delivered snapshot rows are billable when you request them again.

One monitor has a distributed lock to avoid simultaneous output. Do not schedule overlapping runs. The lock expires after 10 minutes if the process is interrupted. Results are checkpointed after each successful output. A crash between output and checkpoint can repeat that same eventId; this is at-least-once delivery, so downstream consumers should deduplicate. Normal completed repeated runs do not emit or charge the same version again.

Material changes currently mean a changed title-derived purchase subject, response date, explicit cancellation or category. Countdown changes do not create events. The feed does not infer withdrawal from a disappearing page, guarantee historical completeness, or diff PDFs/attachments. An API-indexed notice can lag its source by roughly one day; follow the original link for the latest requirements.

Pricing

The pay-per-event price is $0.005 per run plus $0.01 per delivered signal ($10 per 1,000 signals). These are usage charges for recurring monitoring, not a flat monthly subscription. The Store's active pricing controls billing; the Actor fails safely if configured PPE events/prices differ from the contract.

• One run with 12 results: $0.125.
• 30 daily runs and 20 new/updated results in total: $0.35.
• 30 runs with no new result: $0.15 in start events.

A billable unit is one emitted notice/version, not each matching keyword or raw page. No extra synthetic Dataset-item event is permitted. Set an Apify maximum run charge to bound results. Low budgets and maxResults stop output before additional items and leave undelivered items eligible for a later run. A source failure may still incur the automatic run-start event, but emits no signal events.

Sources, permissions and exclusions

This Actor uses the official 官公需情報ポータル API under its API terms. That API is a discovery/extraction channel, not a blanket license for all indexed material. Only the reviewed Forestry Agency procurement paths are accepted. The Forestry Agency's site links to the MAFF content terms, which apply PDL1.0 absent separate rights or restrictions.

Osaka RFI discovery uses the Digital Administration Bureau's official index. Public HTML notices must explicitly display CC BY 4.0. The Actor does not fetch attachments or materials requiring application or a nondisclosure agreement.

Outputs contain selected notice facts and short deadline evidence, processed by Japan Signal Lab. They are not official government analysis or endorsement. Source attribution and license links are included in each row. No logos, photos, maps, third-party reports, officials' contact details, personal addresses or enriched contact lists are distributed. Source rights and coverage decisions are recorded in the repository's docs/source-review.md.

Subsidy project prose and permit-based purchase inference are not included in this version. Government sales/disposals, awards/results, expired notices and superseded versions are filtered conservatively. A generic title such as “goods procurement” stays generic; we do not invent the actual equipment list.

Reliability and limits

Each run makes at most one 官公需 API request (200 candidate notices) and one Osaka index check plus up to 10 relevant HTML pages, with sequential, paced requests and size/time caps. Robots restrictions are respected for Osaka. Source errors fail the run without advancing monitor state. A truncated source is disclosed in SUMMARY; no claim of complete coverage is made. The source HTML/XML structure may change and require maintenance.

Apify Store health checks use the input form prefill, so they exercise a live snapshot rather than consume a persistent change monitor. If no current notice qualifies, the Actor returns zero real records; it never inserts sample or fabricated opportunities to pass a health check.

The Actor uses deterministic rules and the existing Japan Signal Lab patterns for XML processing, Apify metadata and PPE cost guards. It runs separately from the existing Supplier/KYB Actor and preserves that Actor's inputs, outputs, billing and source code.

Local development

From this Actor's directory, run npm ci, npm test, npm run build, and npm run verify:live. The live verifier performs bounded source reads without Apify cloud execution or AI charges and writes its report under work/. Use npm start for a complete local Actor run. Node.js 20 or newer is required.

Before Store release, verify a cloud build, initial and repeat runs, the input/output view, exact PPE configuration, permissions and the public Store page. Local tests alone do not prove a published product or customer demand.