Good Smile Japan JAN Release & Delay Order Checks — Beta

Give this Actor the JANs and row IDs from your preorder sheet. It returns the Japanese dispatch/release evidence, published old→new changes and a manual-review queue, so you can check many orders without searching each product name again.

Public beta: synthetic 20-row workflows and a six-row first-use sample have been verified on Apify. There is no additional Actor fee; users pay ordinary Apify platform usage. External API and hosted MCP smoke tests remain pending.

Supported scope

• Good Smile's public Japanese and English release calendars and schedule announcements only.
• Published release-month delays/advances, explicitly marked Japanese dispatch-date changes, and named release cancellations.
• Optional public Japanese monthly summaries supplement the requested notice history. Summary scope is separate from the linked notice range.
• Month, Japanese dispatch day, wholesaler arrival day and release day have different meanings. None is an overseas delivery estimate.

This is an evidence/review tool: it does not verify your order's preorder batch, certify the current schedule, auto-update orders or prove that no change exists. automaticUpdateAllowed is always false, announcementHistoryComplete is false and nextCursor is null. A missing JAN, incomplete history, conflicting language/batch evidence or failed source remains explicit.

First run: six representative order rows

The prefilled input demonstrates dispatch correction, three successive delays, a Japanese-only month change, a month advance, a batch ambiguity and an unresolved cancellation. It includes the requested notice lookback and monthly supplement, so the value is not reduced to a latest-page search. Copy the example, run it, open Order rows dataset, then read Full evidence JSON, Manual review queue and the CSV downloads. Replace the sample JANs, row IDs and lookback dates with your own orders afterwards.

JANs must be strings and clientItemId must be unique. knownSchedule.kind must describe the date in your sheet: a dispatch day cannot be compared as a release month. Without a baseline, the Actor can still return evidence but cannot suggest an old-to-new transition.

Example input

{
  "items": [
    {"clientItemId": "demo-dispatch-correction", "jan": "4580828671478", "knownSchedule": {"value": "2026-09-18", "kind": "japan_dispatch"}},
    {"clientItemId": "demo-sophia-three-delays", "jan": "4570001514623", "knownSchedule": {"value": "2026-07", "kind": "japan_release_month"}},
    {"clientItemId": "demo-japanese-only-delay", "jan": "4595055216910", "knownSchedule": {"value": "2026-06", "kind": "japan_release_month"}},
    {"clientItemId": "demo-month-advance", "jan": "4580522750325", "knownSchedule": {"value": "2026-10", "kind": "japan_release_month"}},
    {"clientItemId": "demo-second-preorder", "jan": "6977459540118", "knownSchedule": {"value": "2027-01", "kind": "japan_release_month"}},
    {"clientItemId": "synthetic-cancel-4580717791256", "jan": "4580717791256", "knownSchedule": {"value": "2026-10", "kind": "japan_release_month"}}
  ],
  "historySince": "2026-09-01",
  "maxHistoryPagesPerLanguage": 80,
  "monthlyHistorySince": "2026-05-01",
  "maxMonthlySummaryPages": 3,
  "noticeUrls": ["https://www.goodsmile.com/ja/news/6917"],
  "cacheMaxAgeSeconds": 3600
}

These are synthetic order rows using real catalogue identifiers, not customer orders. The dates are a reproducible historical example, not rolling production defaults. For your workflow, set historySince to the needed inclusive announcement publication date, and a sufficient maxHistoryPagesPerLanguage. since only filters returned notifications. An old release month does not identify the necessary lookback by itself. Omitting historySince gives a latest-index diagnostic run; empty events in that mode do not mean there was no delay.

Outputs and next actions

Output	Use
orders.csv / dataset	Join to your order sheet by clientItemId. Read action, baseline, typed published target, timeline, review IDs and source URLs.
REVIEW_QUEUE / reviews.csv	Inspect each shared notice/source review once, then follow its linked order row IDs.
OUTPUT	Full evidence, source/date/budget coverage, unresolved notices and state commit status. Required even when the order CSV has useful results.
RUN_REPORT	Application resource/I/O measurements. Not an invoice or verified execution price.

A publishedChangeSuggestion is a unique chronological transition from your supplied typed baseline in the checked published facts. It remains a manual suggestion, not the currently valid date. Ambiguous branches, conflicting evidence, missing baseline or a mismatched date meaning yield no suggestion.

Cancellation notice 7038 does not contain JANs. The queue supplies four curated retailer catalogue identity hints recorded on 2026-10-08, with product names and URLs, only while the notice's exact names/date/old month match the recorded facts. These are not fetched retailer prices or official JAN cancellation matches. Confirm the original notice and your product/edition manually. Unmatched JANs are not certified unaffected. New named cancellations still appear in the queue without guessing a JAN.

Repeated calls and manual source reviews

For repeated calls, use your own dedicated stateStoreName and run sequentially. This preserves public-source facts, source cache and identity bindings. Same-store concurrent cloud runs are unsupported. Omit the name to use stateless runs.

The caller maintains cumulative seenEventIds and seenChangeIds after successfully handling notifications. observedEventIds contains this run's returned, unprocessed IDs, not the full ledger; a later empty list must not replace your saved acknowledgment list. Fetching evidence does not mark an order updated.

Source facts that changed/disappeared create a separate review. seenChangeIds acknowledges receipt but does not close that review. After inspecting a finding, submit:

{
  "sourceReviewResolutions": [
    {"changeId": "<finding.changeId>", "reviewToken": "<finding.reviewToken>", "decision": "source_change_reviewed"}
  ]
}

Add this to your normal input and reuse the same state store. Tokens are bound to checked facts. A stale token or unavailable source is rejected; later changed/missing facts reopen or retain the review. The resulting decision applies only to this source review: cancellation identity, independent conflicts and incomplete history remain unresolved. Resolution outcomes/audit are returned in the queue. Confirm successful state saving in OUTPUT.coverage.state before relying on persistence.

Practical boundaries

This is an independent tool, not an official Good Smile service and not endorsed by Good Smile. Official source terms retain intellectual-property rights and do not grant a content-reuse license. The outputs identify products and scheduling facts with source links; they do not distribute page HTML, product imagery or logos. Any internal public-page cache is for sequential source checks, not a public content archive. robots.txt permission is a technical crawl signal, not a license. Recheck source terms before expanding reuse or distributing a bulk historical data product.

Keep private customer details out of the input; only order row IDs, JANs and Japanese baseline dates are needed. Inputs/results remain in your Apify run storage; do not publish sample output containing real customer identifiers. The named state contains public source facts rather than an order database.

The Actor uses allowlisted public sources, checks robots, limits request size/intervals and stops or reports failures rather than solving login/CAPTCHA or silently using expired sources. TTL cache hits are not fresh HTTP reads. cacheMaxAgeSeconds: 0 requests source revalidation. Source changes may require maintenance.

In private tests on 2026-10-09, a 20-row synthetic batch with September linked history and May monthly summaries took about 104 seconds on first retrieval, 4 seconds with fresh cache, and 103 seconds with forced source revalidation. Console displayed approximately $0.004, $0.001 and $0.004 in platform usage respectively (rounded; excludes timed storage and future reads). These are test observations, not Store prices, guarantees or final invoices. There is no additional Actor fee; ordinary platform usage is charged by Apify. Longer history requires more source work; no per-JAN cost or maximum commercial batch size is claimed yet.

API and AI/MCP use

Use the asynchronous Apify run endpoint, then wait for SUCCEEDED and retrieve the run's OUTPUT and REVIEW_QUEUE key-value records alongside the dataset/CSVs. A dataset alone omits run-level source failures and unresolved notices. Send your token in the Authorization header, keep it in your client environment and never include it in a URL or a shared prompt. The documented API workflow is prepared; a separate authenticated external API smoke test is still pending.

For MCP, connect your client to the hosted Apify MCP server using its OAuth flow. Use the Actor's exact slug amycole/jan-japan-release-delay-checks-beta and fetch its schema before calling it. The Actor is public; authenticate your API/MCP client with your own Apify account to run it and read your private results. Ask the agent to preserve JAN strings, row IDs, typed baselines, coverage, manual-review tasks and cumulative acknowledgment IDs. Never instruct it to treat incomplete_history, not_listed or an empty notification list as unchanged, or to overwrite order dates automatically. call-actor returns status and storage IDs and waits at most 45 seconds, so a cold history run may still be running. Poll get-actor-run until SUCCEEDED; do not start a duplicate. Then use get-dataset-items and get-key-value-store-record to read OUTPUT and REVIEW_QUEUE. Put run limits in callOptions, not in the Actor input. Hosted MCP authentication and an actual Actor call have not yet been verified for this beta.

An appropriate request is: “Check these preorder rows against Good Smile Japan notices since this date. Return the typed published transitions, source links and manual-review tasks. Do not update my order sheet. Read full OUTPUT coverage before summarizing.”