APIFuse

Public changelog

APIFuse changes customers should know about

Public API, provider operation, lifecycle, and migration updates are listed here from the validated APIFuse changelog source.

Browse API reference

Generated from OpenSpec changelog entries at 2026-07-10T11:40:33.000Z.

  1. BreakingShipped

    Weverse public community, artist, media, and shop-catalog reads no longer require a Weverse connection; CatchTable and Hot Pepper Gourmet public reads now declare their existing connection-less behavior explicitly.

    ## Weverse public reads no longer require a Connection Weverse public reads were previously forced to require an APIFuse Connection because the provider authenticates with credentials for its account and personalized operations. That over-gated genuinely public endpoints: the Weverse main API serves community, artist, member, post, comment, media, and shop-catalog reads anonymously using only the public web request signature. These 39 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Connection is still required only for operations that read the signed-in user's own state or perform account actions: `connection-health`, `get-account-info`, `get-current-user`, `get-dm-user`, `get-jelly-balance`, `get-membership-benefits`, `get-my-membership`, `get-unseen-notification-count`, `get-user-settings`, `list-dm-subscriptions`, `list-showcased-rooms`, `shop-cart-count`, and `shop-logout`. ## CatchTable and Hot Pepper Gourmet: explicit connectionMode (no behavior change) As part of making `connectionMode` an explicit, lint-enforced field on every operation, the CatchTable public reads (`availability`, `reviews`, `search`, `shop`) and Hot Pepper Gourmet public reads (`availability`, `master-data`, `restaurant-detail`, `search-restaurants`, `time-slots`) now declare `connectionMode: "none"` in source. These operations were already connection-less at runtime; only their contract representation changed from an implicit default to an explicit declaration, which shifts their compatibility hash without changing behavior. Existing callers are unaffected.

    Affected surface
    weverse/get-app-state, weverse/get-artist-highlight, weverse/get-comment, weverse/get-community, weverse/get-community-tab, weverse/get-live-tab, weverse/get-member, weverse/get-post, weverse/get-posts, weverse/list-category-media, weverse/list-comment-artist-replies, weverse/list-comment-replies, weverse/list-community-all-media, weverse/list-community-media-categories, weverse/list-fan-letter-posts, weverse/list-feed-posts, weverse/list-group-communities, weverse/list-groups, weverse/list-live-posts, weverse/list-media-group-posts, weverse/list-member-comments, weverse/list-member-posts, weverse/list-post-artist-comments, weverse/list-post-comments, weverse/resolve-community, weverse/search-communities, weverse/shop-artist-banners, weverse/shop-artist-recent-sales, weverse/shop-home-banners, weverse/shop-home-notices, weverse/shop-marketing-banners, weverse/shop-pickup-banner, weverse/shop-pickup-detail, weverse/shop-pod-sales, weverse/shop-recent-sales, weverse/shop-recommend-sales, weverse/shop-recommended-sales, weverse/shop-return-exchange-info, weverse/shop-sale-curation, catchtable/availability, catchtable/reviews, catchtable/search, catchtable/shop, hotpepper-gourmet/availability, hotpepper-gourmet/master-data, hotpepper-gourmet/restaurant-detail, hotpepper-gourmet/search-restaurants, hotpepper-gourmet/time-slots
    Action required
    No
    Migration guidance
    The 39 Weverse read operations listed here now run without X-ApiFuse-Connection-Id (community metadata, posts, comments, members, media, and shop catalog/banner content). Existing callers that still send a connection keep working unchanged. Weverse operations that read the signed-in user's own state or account still require a connection (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout). The CatchTable (availability, reviews, search, shop) and Hot Pepper Gourmet (availability, master-data, restaurant-detail, search-restaurants, time-slots) reads did not change behavior: they were already callable without a connection and now declare connectionMode "none" explicitly instead of relying on an implicit default.
  2. BreakingShipped

    Superseded stopgap: CatchTable waiting status and waiting menu calls temporarily required a connected CatchTable account before optional waiting reads shipped.

    This entry records the temporary login-required stopgap for CatchTable waiting reads. It is superseded by `catchtable-waiting-optional-connection`: waiting-info and waiting-menus can now be called anonymously for public read data, while connected calls continue to return connection-bound choice tokens before registration.

    Affected surface
    catchtable/waiting-info, catchtable/waiting-menus
    Action required
    No
    Migration guidance
    This stopgap has been superseded by catchtable-waiting-optional-connection. Existing connected callers can keep sending X-ApiFuse-Connection-Id for waiting_choice and menu_choice tokens. Anonymous callers can now call catchtable/waiting-info and catchtable/waiting-menus for public waiting status and menu data without choice tokens.
  3. BreakingShipped

    CatchTable waiting status and waiting menu calls can now be read without a CatchTable connection, while connected calls keep returning choice tokens for waiting registration.

    CatchTable waiting reads now support anonymous discovery and connected choice-token enrichment. Anonymous `waiting-info` returns queue status, open/remote-waiting flags, waiting table details, and person-option labels without opaque choice tokens. Anonymous `waiting-menus` returns categories and menu details without `menu_choice` values. When a CatchTable connection is supplied, both operations behave as before and return connection-bound choice tokens for `register-waiting`.

    Affected surface
    catchtable/waiting-info, catchtable/waiting-menus
    Action required
    No
    Migration guidance
    Existing connected callers can keep sending X-ApiFuse-Connection-Id and will receive waiting_choice, person_option_choice, additional_option_choice, and menu_choice tokens as before. Anonymous callers may now call catchtable/waiting-info and catchtable/waiting-menus without a connection to read public waiting status, person-option labels, and menu data; connect first when the user wants to register waiting, because anonymous responses do not include choice tokens.
  4. BreakingShipped

    KakaoMap provider contracts now resolve route endpoint strings, return richer place/review/search data, and normalize route and transit-info fields.

    KakaoMap operations now expose APIFuse-standard, agent-actionable contracts. Search and place/review additions are optional enrichments when KakaoMap provides the data. Search coordinates are converted to KakaoMap's WCONGNAMUL plane coordinates before upstream place search, `sort_by: "distance"` maps to KakaoMap `USER_DISTANCE`, and ratings are emitted only from a rating source that has participants. Route and transit-info renames are intentional hard-breaking cleanup for Development-stage public contract quality.

    Affected surface
    kakaomap/search, kakaomap/place, kakaomap/place-reviews, kakaomap/car-directions, kakaomap/walk-directions, kakaomap/bicycle-directions, kakaomap/transit-directions, kakaomap/transit-info
    Action required
    Yes
    Migration guidance
    For search and transit directions, replace public `sort` with `sort_by`. For search, `sort_by: "distance"` now requires both `lat` and `lng`, and the previously exposed `radius` input has been removed because KakaoMap ignored it. For route outputs, replace transit `duration`, `walkTime`, and `transitTime` with `duration_sec`, `walk_sec`, and `transit_sec`; replace car `fare` with `toll_fee` or `taxi_fee`. For transit-info, branch on top-level `info_type` and read normalized fields such as `stop_id`, `lng`, `vehicle_locations`, `realtime_state_message`, `station_id`, `station_name`, and `subway_line_name` instead of upstream-shaped names. Route callers may keep coordinate pairs or switch to `origin` and `destination` strings.
  5. BreakingShipped

    KakaoMap boolean inputs now require JSON booleans instead of string boolean values.

    KakaoMap now matches the standard APIFuse provider boolean contract. Boolean control fields fail closed unless callers send actual JSON booleans, removing the temporary string-boolean compatibility path introduced during earlier `open_now` coercion cleanup.

    Affected surface
    kakaomap/search, kakaomap/place, kakaomap/place-reviews, kakaomap/car-directions
    Action required
    Yes
    Migration guidance
    Update KakaoMap callers to send `open_now`, `include_reviews`, `include_photos`, `include_blog`, and `has_hipass` as JSON booleans (`true` or `false`). String values such as `"true"` and `"false"` are no longer accepted.
  6. BreakingShipped

    KakaoMap operations gain route options, transit sorting and alighting info, composite place fetches, search filters, and geocode bias inputs.

    KakaoMap provider operations now match the full feature surface of the vooy KakaoMap connector while keeping APIFuse-standard naming. Car directions accept waypoints, avoid options, route priority, vehicle size class, and Hi-Pass state. Transit directions sort itineraries provider-side by time, transfer count, or walking time, cap results, and expose alighting guidance (fast exit doors, fast transfer doors, exit direction). Place detail can inline reviews, photos, and benefits in one call with explicit opt-outs, and place reviews paginate with `page_size`. Search returns the dynamic `available_filters` vocabulary and accepts its `filter_tag` tokens for filtered searches. Geocode accepts an optional coordinate bias pair and no longer implies place-name support.

    Affected surface
    kakaomap/search, kakaomap/geocode, kakaomap/place, kakaomap/place-reviews, kakaomap/car-directions, kakaomap/transit-directions
    Action required
    Yes
    Migration guidance
    For car directions, send `vehicle_type` ("compact", "medium", "large") and `has_hipass` for fuel and toll computation; new optional `waypoints` (max 3), `avoid`, and `priority` inputs control routing. For transit directions, `sort_by` now accepts `walk` and `transfer` in addition to `time` (sorting is applied by the provider because KakaoMap ignores its sort parameter), `max_results` caps itineraries, and steps may include `fast_exits`, `fast_transfers`, and `exit_direction`. For place, use `include_reviews`, `include_photos`, and `review_limit` to control composite enrichment; `confirm_id` must be the numeric KakaoMap place id. For place-reviews, use `page_size` for pagination. For search, pass `filter_tag` tokens taken from the new `available_filters` field of a prior search response; free-text filter labels are not accepted. For geocode, optional `lat` and `lng` bias inputs must be provided together and the input must be an address, not a place name.
  7. EmergencyShipped

    Yogiyo menu option section arrays now default to empty arrays when upstream omits them, preventing healthy menu discovery responses from being rejected.

    Yogiyo occasionally omits nested option arrays on slim menu payloads used by health discovery and option lookup flows. The provider already treats missing option detail as an empty selectable option list when building menu summaries, but the public output schema still required nested `options` arrays and could reject otherwise valid normalized responses This emergency compatibility fix aligns the public schema with the runtime normalization: missing nested option arrays are defaulted to `[]`. The change is backward-compatible for clients because the emitted field remains an array; it only removes a false schema rejection path

    Affected surface
    yogiyo/menu-item-options, yogiyo/restaurant-full
    Action required
    No
    Migration guidance
    No caller changes required. Responses that previously could fail schema validation when Yogiyo omitted option arrays now normalize those missing arrays to []. Existing callers should continue to treat options as an array and handle the empty-array case.
  8. PatchShipped

    CatchTable cancel-waiting no longer fails on successful upstream cancellations whose response body omits waitingRef/status.

    CatchTable cancel-waiting previously required the cancellation response body to echo the waiting reference and a cancelled status. Successful cancellations that returned an empty or minimal response were misreported as `UPSTREAM_SCHEMA_ERROR` even though the waiting had been cancelled. The response body is now treated as opaque success confirmation. Error responses still fail, and if the body does echo a waiting reference it must match the requested one.

    Affected surface
    catchtable/cancel-waiting
    Action required
    No
    Migration guidance
    No caller changes required. `cancel-waiting` keeps returning `{ waiting_ref, status: "CANCELLED" }`; the operation now succeeds when cancellation is accepted, instead of rejecting response bodies that do not echo `waitingRef`/`status`.
  9. AddedShipped

    CatchTable gains a my-bookmarks operation that lists the authenticated user's saved (bookmarked) shops.

    `catchtable/my-bookmarks` is a new read-only operation that returns the authenticated user's saved (bookmarked) CatchTable shops. It takes no input and returns `bookmarks`, a list where every row carries `shop_ref` — the identifier accepted by `catchtable:shop`, `catchtable:reviews`, and `catchtable:availability` — plus `shop_name` when CatchTable includes the display name. An empty `bookmarks` list is a normal response for accounts with no saved shops. Like the other account-scoped CatchTable operations, it requires a connected CatchTable account: calls without a usable session fail with `AUTH_REQUIRED`, and upstream session rejections surface as upstream errors with safe diagnostics.

    Affected surface
    catchtable/my-bookmarks
    Action required
    No
    Migration guidance
    none
  10. BreakingShipped

    CatchTable reserve and reservation-detail now report AWAITING_SHOP_CONFIRMATION for reservations the shop has not confirmed yet, instead of failing after creation or mislabeling them CONFIRMED.

    CatchTable creates some dining reservations in a shop-confirmation-pending state: the reservation exists upstream, but the shop still has to accept it before it is a confirmed booking. The upstream create and detail payloads mark this with awaiting signals (`awaitingLevel`, `confirmingReservation`) rather than a status string. `reserve` previously recognized only immediately confirmed reservations. For confirmation-pending shops it threw `UPSTREAM_ERROR` after the reservation had already been created upstream, leaving callers with a live reservation they never learned about. It now returns `status: "AWAITING_SHOP_CONFIRMATION"` for those creations. The status is a hard product distinction: an awaiting reservation must never be presented as confirmed. Responses with an unrecognized explicit upstream status keep failing closed, with the upstream value named in the error. `reservation-detail` previously defaulted every non-cancelled reservation to `CONFIRMED`. It now derives the status from the upstream cancellation and awaiting signals and returns the closed enum `CONFIRMED | AWAITING_SHOP_CONFIRMATION | CANCELLED`, so a pending reservation can be distinguished from a confirmed one when polling after `reserve`.

    Affected surface
    catchtable/reserve, catchtable/reservation-detail
    Action required
    Yes
    Migration guidance
    "`reserve` `status` is still a closed enum but now returns `AWAITING_SHOP_CONFIRMATION` in addition to `CONFIRMED`. Shops that review requests before accepting them create the reservation upstream in a confirmation-pending state; `reserve` previously failed those calls with `UPSTREAM_ERROR` even though the reservation already existed on CatchTable. Callers must handle the new value: treat it as \"request placed, awaiting the shop's confirmation\" and never present it to end users as a confirmed booking — CatchTable notifies the user once the shop confirms, and `reservation-detail` can be polled for the current state. `reservation-detail` `status` changes from a free-form string to the closed enum `CONFIRMED | AWAITING_SHOP_CONFIRMATION | CANCELLED`; it previously reported `CONFIRMED` for every non-cancelled reservation, including ones the shop had not confirmed. Callers that branched on other string values must switch to these three statuses."
  11. BreakingShipped

    CatchTable search now returns a next_offset pagination cursor and per-shop main_service (DINING/WAITING), and the offset input carries the opaque cursor string instead of a numeric page offset.

    CatchTable search previously exposed only `shops` and `total`, and its `offset` input was declared as a number. Upstream `/api/v6/search/list` actually paginates with an opaque cursor: each page returns `paging.hasMore` plus a `paging.nextOffset` cursor string, and requesting any numeric offset other than `0` fails upstream with HTTP 500 (verified live 2026-07-07), so results beyond the first page were unreachable. The `offset` input is now that cursor: `"0"` (default) for the first page, then the previous response's `next_offset` verbatim. `next_offset` is emitted only while `paging.hasMore` is true; on the last page upstream answers `{ hasMore: false, nextOffset: "0" }` and the reset cursor is not a next page, so the field is omitted — its absence is the end-of-results signal. Each shop row now also reports `main_service`, the shop's primary CatchTable service observed live and in captured fixtures as a closed `DINING` / `WAITING` vocabulary. `DINING` shops are reservation-led (continue with `availability` and the reservation operations); `WAITING` shops are waitlist-led (continue with `waiting-info`, which remains the authority on whether remote waiting registration is actually open). A shop row without the upstream field simply omits `main_service`; an unknown value fails closed with `UPSTREAM_ERROR` so new upstream vocabulary surfaces as a visible contract signal instead of a silent guess.

    Affected surface
    catchtable/search
    Action required
    Yes
    Migration guidance
    "`search` output adds two fields: top-level `next_offset` (opaque cursor string, present only while more results remain — absent means the last page) and per-shop `main_service` (`DINING` for reservation-led shops, `WAITING` for waitlist-led shops; route WAITING shops through `waiting-info` before registering a waiting). The `offset` input is now the pagination cursor: send `\"0\"` (or omit it) for the first page and pass the previous response's `next_offset` unchanged for the next page. Numeric `offset: 0` keeps working for the first page, but other computed numeric offsets were never functional — CatchTable rejects them with HTTP 500 — so callers that incremented `offset` must switch to `next_offset`. An unrecognized upstream `main_service` value fails the call with `UPSTREAM_ERROR` instead of being silently dropped."
  12. BreakingShipped

    CatchTable shop now returns the full detail surface (business hours, holidays, parking, cancellation policy, reservation notes, lunch/dinner price ranges, facilities, open schedules, the priced menu, and nearby subway stations) and honors include_reviews/review_limit.

    The CatchTable `shop` operation previously returned a 9-field subset (identity, address, phone, description, images, rating, review count), while its `include_reviews` and `review_limit` inputs were accepted but ignored. Users asking about 영업시간, 주차, 메뉴, or 취소 정책 could not get answers from this operation. `shop` now returns the richer public detail surface: - `biz_hours`, `holidays`, `parking`, `cancel_policy`, `reservation_note`, `lunch_price`, `dinner_price`, `facilities`, and `open_schedules`. These guide fields are optional: shops that do not publish a guide omit the field instead of receiving a fabricated value. - `menu`: menu-board image URLs and menu categories whose items carry `min_price`/`max_price` in KRW (omitted when the shop does not publish a bound), descriptions, recommended/representative flags, and image URLs, plus kids-menu and allergy-substitute guides when the shop enables them. - `subways`: nearby stations with line codes and walking-distance display text. `include_reviews=true` now returns recent reviews (up to `review_limit`) under `reviews` with the same `{reviews[], total}` shape as the `reviews` operation. Partial data failures fail closed. If required detail, menu, subway, or requested review data cannot be loaded, the operation raises `UPSTREAM_ERROR` instead of silently degrading to the legacy 9-field subset. The shop health probe now also verifies the enriched surface (business hours present, at least one priced menu item, and nearby subway data) for the canary shop.

    Affected surface
    catchtable/shop
    Action required
    Yes
    Migration guidance
    "`shop` output gains additive fields: optional strings `biz_hours`, `holidays`, `parking`, `cancel_policy`, `reservation_note`, `lunch_price`, `dinner_price`, optional `facilities` (string array), `open_schedules` (array of `{schedule_type, open_time}`), required `menu` (`{menu_boards, categories[{name, description, items[{name, min_price, max_price, description, is_recommended, is_representative, image_url}]}], kids_menu_guide, allergy_guide}`), and required `subways` (array of `{station, lines, distance}`). The previously accepted-but-ignored inputs `include_reviews`/`review_limit` are now honored: with `include_reviews=true` the output additionally carries `reviews` in the same `{reviews[], total}` shape as the `reviews` operation, limited to `review_limit`. Error behavior changed from partial tolerance to fail-closed: if required detail, menu, subway, or requested review data cannot be loaded, the operation now fails with `UPSTREAM_ERROR` instead of silently returning the legacy 9-field subset. Callers that only read the original 9 fields need no changes."
  13. AddedShipped

    CatchTable gains a waiting-detail operation that returns the live detail of a single waiting entry, preferring the realtime queue position.

    `catchtable/waiting-detail` is a new authenticated read-only operation for a single CatchTable waiting entry. Previously only `my-status` exposed waiting state, limited to `waiting_ref`, `shop_name`, `waiting_order`, and `status` across all active waitings. `waiting-detail` takes the `waiting_ref` from `register-waiting` or `my-status` and returns `waiting_number`, `waiting_order`, `status`, `table_name`, `person_count`, `registered_at`, `check_in_status`, and `put_off_type` alongside the shop identity. `waiting_order` prefers the realtime queue position from CatchTable's live delay lookup. When that realtime branch is unavailable, the operation falls back to the order captured on the waiting record instead of failing, and reports which branch produced the number via `waiting_order_source` (`realtime` or `registered`). The operation is continuously verified inside the probe-owned waiting lifecycle health journey (register → detail → cancel), so its status is measured with a real waiting entry rather than a synthetic fixture.

    Affected surface
    catchtable/waiting-detail
    Action required
    No
    Migration guidance
    No changes are required for existing operations. Call the new `waiting-detail` with the `waiting_ref` returned by `register-waiting` or `my-status` to read the current queue position, waiting number, status, table name, registration time, check-in status, and put-off type for one waiting entry.
  14. BreakingShipped

    CatchTable register-waiting now returns the customer-facing waiting_number and shop_name, and cancel-waiting sends the first-party cancelReasonCode body with reason narrowed to the closed CUSTOMER_CANCEL vocabulary.

    This release closes two contract-fidelity gaps in the CatchTable waiting write path. **register-waiting output.** CatchTable's register response includes the customer-facing waiting ticket number (`waitingNumber`, the 대기 번호 shown at the shop) and the shop name (`shopName`). The operation previously dropped both. It now returns them as optional `waiting_number` and `shop_name` output fields — optional because the upstream contract does not guarantee them — so agents can tell users their actual ticket number instead of only the queue position (`waiting_order`). **cancel-waiting reason.** The operation accepted an optional free-form `reason` string but ignored it and posted `POST /reservation-api/v1/waitings/{ref}/cancel` with no body. The CatchTable app frontend always cancels with the body `{"cancelReasonCode": "CUSTOMER_CANCEL"}`. The handler now mirrors that exactly, and `reason` is a closed enum whose only evidenced value is `CUSTOMER_CANCEL`, defaulting to `CUSTOMER_CANCEL` when omitted. Human-readable aliases (for example `cancel` or `취소`) are intentionally rejected rather than silently normalized.

    Affected surface
    catchtable/register-waiting, catchtable/cancel-waiting
    Action required
    Yes
    Migration guidance
    "`register-waiting` gains two optional output fields: `waiting_number` (the 대기 번호 ticket number the shop displays to the customer) and `shop_name`; existing fields are unchanged, so readers only need updates if they validate the response with a closed schema. `cancel-waiting` `reason` is narrowed from a free-form optional string to the closed enum `[\"CUSTOMER_CANCEL\"]` with default `CUSTOMER_CANCEL` — the same code the CatchTable app frontend always sends. The old `reason` parameter was dead: the previous handler ignored it and posted the cancel with no body, so no caller behavior depended on its value. Callers that passed arbitrary reason text (for example \"changed my mind\") will now fail input validation; omit `reason` or send `CUSTOMER_CANCEL`. The cancel request now posts `{\"cancelReasonCode\": \"CUSTOMER_CANCEL\"}` to CatchTable, matching the first-party client instead of an empty body."
  15. BreakingShipped

    Yogiyo restaurant-full menu list items drop per-item image URLs and cap descriptions at 100 characters; menu-item-options now returns the full description and image URL for one selected item.

    `yogiyo/restaurant-full` menus routinely carry 100+ items, and the per-item image URLs plus full descriptions pushed large shops past downstream agent tool-result budgets (a 123-item shop serialized to ~76.5KB). The menu list projection is now compact: `image_url` is removed from list items, and `description` is capped at 100 characters with a single trailing `…`. Existing option count summaries stay on each item: `has_options`, `option_section_count`, `required_option_section_count`, `optional_option_section_count`, and `option_item_count`. `menu_metrics` continues to report full aggregate counts. The same 123-item shop now serializes to ~35KB. `yogiyo/menu-item-options` remains the single-item detail surface and now also returns the full untruncated `description` and the item `image_url` when Yogiyo exposes them, alongside the existing option sections and option counters. Callers that rendered menu images or full descriptions from `restaurant-full` should fetch them per selected item via `menu-item-options` with the same `shop_id` and `item_id`.

    Affected surface
    yogiyo/restaurant-full, yogiyo/menu-item-options
    Action required
    Yes
    Migration guidance
    restaurant-full menu list items no longer include image_url, and description is truncated to 100 characters with a trailing …. Existing option count summaries stay on every list item: has_options, option_section_count, required_option_section_count, optional_option_section_count, and option_item_count. menu_metrics keeps full aggregate counts. Callers that need the untruncated description or the menu image should call menu-item-options with the same shop_id and the selected item_id; its response now includes description and image_url when Yogiyo exposes them.
  16. BreakingShipped

    CatchTable waiting-info and register-waiting now model person-option choices required by upstream waiting registration.

    CatchTable waiting registration now matches the current first-party web bundle for shops that require explicit person-option distribution. `waiting-info` exposes APIFuse opaque person-option choices, including additional person-option choices when present, and `register-waiting` accepts those choices instead of raw upstream identifiers This is a public contract expansion for CatchTable waiting flows. Callers that do not encounter person-option requirements do not need to change, but callers should surface the new `person_options` choices when `waiting-info` returns them so registration does not fail upstream with missing person-option selections

    Affected surface
    catchtable/waiting-info, catchtable/register-waiting
    Action required
    No
    Migration guidance
    Existing callers that only register simple waiting shops can keep using `waiting_choice` and `person`. For shops where `waiting-info` returns `person_options`, pass `register-waiting.person_options[]` using the opaque `person_option_choice` and optional `additional_option_choice` tokens returned by `waiting-info`; the selected person-option counts must add up to `person`. Do not construct raw upstream person-option IDs.
  17. BreakingShipped

    Modu Parking location labels now geocode through upstream place search, monthly/period tickets return full detail instead of failing, and price_per_hour is a true hourly rate.

    This release fixes four production-impacting Modu Parking contract behaviors. **Location geocoding.** `search-parking` previously recognized only three hard-coded place labels and silently fell back to a fixed 남산 coordinate for every other label while echoing the requested label back in `searched_location`. Location labels are now geocoded through Modu Parking's first-party place search. Labels that do not resolve fail with `LOCATION_RESOLVE_FAILED`, and calls with neither coordinates nor a non-empty `location` are rejected at input validation (the `location` input no longer declares a default empty string). When a label is geocoded, `searched_location` reports the resolved place name. Explicit `lat`/`lng` coordinates keep taking precedence and skip geocoding entirely. **Monthly/period ticket detail.** `parking-detail` previously hard-failed for every 월주차권/월정기/정기권 ticket because the upstream daily-able-time endpoint deterministically returns `400` vendor code `10812` for them. The operation now tolerates exactly that signature and returns the full ticket detail with `available_days: []` plus a new boolean output field `daily_schedule_supported` (`false` for monthly/period tickets, `true` when upstream returned a daily schedule). Because these tickets cannot be purchased through `start-payment`, they also report `is_purchasable: false` — hand users off via `app_url` instead of starting the SMS ceremony. Tickets that do not exist upstream now fail with the new `TICKET_NOT_FOUND` error code from the detail endpoint. `start-payment` rejects monthly/period tickets with `NOT_PURCHASABLE` before verifying the SMS code or creating any payment request, matching the upstream app, which offers no daily-time purchase flow for them; note that the verification SMS itself is sent by the separate `send-payment-sms` operation, so gate on `is_purchasable` before requesting the SMS. **Hourly rate.** `check-availability` `price_per_hour` previously echoed the first priced slot's total price regardless of the slot duration. It is now derived as `round(price × 60 / using_time_minutes)` from the first priced slot, so a 30-minute 900 KRW slot reports 1800 KRW per hour. **Auth resilience.** Shared-parking availability reads now refresh their internal guest session once when Modu Parking rejects it, instead of failing repeatedly until natural expiry; a rejection that persists after refresh surfaces as a non-retryable upstream error (`UPSTREAM_ERROR`) whose message names the rejected guest session.

    Affected surface
    modu-parking/search-parking, modu-parking/parking-detail, modu-parking/check-availability, modu-parking/start-payment
    Action required
    Yes
    Migration guidance
    "`search-parking` location labels are now geocoded through Modu Parking's own place search instead of a 3-entry lookup that silently searched 남산 for unknown labels: unresolvable labels fail with `LOCATION_RESOLVE_FAILED`, requests with neither coordinates nor a non-empty location are rejected at input validation (the `location` input no longer declares a default empty string — send `lat`/`lng` or a non-empty `location`), and `searched_location` now returns the resolved place name. `parking-detail` for monthly/period tickets (월주차권/정기권) now returns 200 with `available_days: []`, the new `daily_schedule_supported: false` field, and `is_purchasable: false` instead of failing; callers that treated any `parking-detail` failure as \"ticket not found\" must instead branch on the new `TICKET_NOT_FOUND` error code, which is now returned only for tickets that do not exist upstream. Monthly/period tickets cannot be purchased through `start-payment`: it rejects them with `NOT_PURCHASABLE` before verifying the SMS code or creating any payment request, so check `is_purchasable` before calling `send-payment-sms` (that separate operation sends a real SMS and takes no ticket reference) and hand users off via the `parking-detail` `app_url`. `check-availability` `price_per_hour` is now a derived hourly rate (`round(price × 60 / using_time_minutes)` of the first priced slot) instead of echoing the first slot's total price; a 30-minute 900 KRW slot now reports 1800, not 900."
  18. EmergencyShipped

    Yogiyo restaurant details now include a small structured review sample, and a dedicated review lookup operation is available.

    `yogiyo/restaurant-full` now returns a small `reviews` sample when `include_reviews` is true. The sample is capped at three normalized, comment-bearing review rows and keeps optional review details only when Yogiyo exposes them. `yogiyo/restaurant-reviews` is a new read-only operation for fetching normalized reviews for one Yogiyo `shop_id`. It defaults to five reviews and accepts `limit` and `page` for explicit pagination. Existing `restaurant-full` callers do not need to change unless they want to render the new structured review sample.

    Affected surface
    yogiyo/restaurant-full, yogiyo/restaurant-reviews
    Action required
    No
    Migration guidance
    Existing restaurant-full callers can keep their current integration. When include_reviews is true, restaurant-full may now include reviews with up to three normalized comment-bearing review rows alongside review_summary.sample_comments. Call restaurant-reviews with shop_id for a dedicated review list; it defaults to five reviews and supports limit and page.
  19. BreakingShipped

    Daangn region-scoped searches now require opaque region_id values returned by search-regions.

    This is a breaking Daangn Marketplace provider contract change. Region-scoped listing and complex searches no longer accept free-text `region` values. They now require `region_id`, an APIFuse opaque region id returned by the new `search-regions` operation. The cutover prevents silent upstream misses for colloquial or landmark-style place names such as 홍대입구. Callers must explicitly discover a Daangn administrative region first, inspect the returned candidates, and pass `items[].id` into the dependent search operation. `search-regions` returns successful empty results as `items: []` when Daangn does not resolve a keyword, allowing callers to handle unsupported place names without treating them as provider failures.

    Affected surface
    daangn-marketplace/search-regions, daangn-marketplace/used-goods-search, daangn-marketplace/realty-search-listings, daangn-marketplace/jobs-search, daangn-marketplace/cars-search, daangn-marketplace/realty-search-complexes
    Action required
    Yes
    Migration guidance
    Call `daangn-marketplace/search-regions` with a Korean administrative-region keyword, then pass one returned `items[].id` as `region_id` to `used-goods-search`, `jobs-search`, `cars-search`, `realty-search-listings`, or `realty-search-complexes`. The previous free-text `region` input has been removed from those operations.
  20. BreakingShipped

    Yogiyo restaurant-full now returns compact option-count summaries, detailed options move to menu-item-options, and top-level action_hint orchestration strings are removed from Yogiyo responses.

    Yogiyo menu option details are now retrieved per selected menu item. `restaurant-full` keeps the full menu surface compact by returning item/category identifiers, sold-out and web-ordering evidence, and option-count summaries such as `has_options`, `required_option_section_count`, `optional_option_section_count`, and `option_item_count`. Callers that need order option ids should call `menu-item-options` after the user chooses one menu item. That response contains the selected item's option sections and option ids for `order-preview`. Yogiyo provider responses also no longer include top-level `action_hint` strings. Consumers that need a guided checkout flow should derive it from stable response state and keep tool-call or presentation policy in their own application layer.

    Affected surface
    yogiyo/find-restaurants, yogiyo/restaurant-full, yogiyo/menu-item-options, yogiyo/order-preview, yogiyo/verify-phone, yogiyo/confirm-phone, yogiyo/place-order
    Action required
    Yes
    Migration guidance
    Clients that previously read option section ids and option ids directly from restaurant-full menu items should first select a menu item from restaurant-full, then call menu-item-options with the same shop_id and selected item_id. Use menu-item-options.option_sections to populate order-preview items[].options, and keep using restaurant-full menu item id/category_id values for item selection. Stop reading Yogiyo top-level action_hint fields; derive presentation and follow-up behavior from structured response state such as has_options, required_option_section_count, can_place_order, blockers, requires_sms_verification, requires_user_confirmation, success, payment_url, and display values.
  21. BreakingShipped

    Daiso public responses now reject empty product/store identity fields and search-products returns explicit next-action guidance for pickup availability workflows.

    Daiso product and store result schemas now require non-empty public identity fields so downstream callers do not receive structurally valid but unusable rows. `search-products` also exposes machine-readable chaining guidance through `next_action` and `action_hint` for the product search → store search → pickup availability flow.

    Affected surface
    daiso/browse-catalog, daiso/check-pickup-availability, daiso/recommend-products, daiso/search-products, daiso/search-stores, daiso/search-trends, daiso/site-metadata, daiso/store-detail
    Action required
    No
    Migration guidance
    Existing callers can continue using the same operations. Clients should treat missing or empty product_id, name, store_code, or store_name as an upstream schema error instead of relying on empty-string placeholders, and may use search-products next_action/action_hint to chain into search-stores and check-pickup-availability.
  22. BreakingShipped

    Korea Weather short forecast responses now use a structured v2 weather model with nested current observation, hourly forecasts, and wind fields.

    The Korea Weather provider now separates KMA upstream category codes from the APIFuse public response model. Current observations are grouped under `current_observation`, hourly forecast rows are grouped under `hourly_forecasts`, and wind values from `WSD`, `VEC`, `UUU`, and `VVV` are normalized into a semantic `wind` object. This hardcut also accepts live KMA current-observation `VEC` categories and maps them to `wind.direction` instead of failing with `UPSTREAM_SCHEMA_ERROR`.

    Affected surface
    korea-weather/short-forecast, korea-weather/weather-by-address
    Action required
    Yes
    Migration guidance
    Update clients that read `korea-weather/short-forecast` or `korea-weather/weather-by-address.forecast`. The short forecast payload now returns `grid`, `current_observation`, and `hourly_forecasts`. Replace top-level `observed_at`, `temperature`, `humidity`, `wind_speed`, `precipitation_1h`, `precipitation_type`, and `sky` reads with `current_observation.*`. Replace `wind_speed` with `current_observation.wind.speed`; read wind direction from `current_observation.wind.direction`. Replace `forecasts` with `hourly_forecasts`; forecast entries now include nested `wind` and `humidity` fields. Operation contract versions for `short-forecast` and `weather-by-address` are now `2.0.0`.
  23. BreakingShipped

    CatchTable reservation date/time public output fields now always use ISO YYYY-MM-DD and 24-hour HH:MM; compact upstream vendor formats no longer leak.

    CatchTable's upstream API returns compact vendor temporal formats (`YYMMDD`/`YYYYMMDD` dates, `HHMM` times) on some reservation fields. Previously the `reservation-detail`, `my-status`, and `reserve` public outputs forwarded those raw values for `visit_date` / `visit_time` without normalization, while the `availability` path already normalized them. This asymmetry leaked non-standard formats into the public contract. These outputs now normalize every temporal field to the APIFuse standard (ISO `YYYY-MM-DD` for dates, 24-hour `HH:MM` for times) before schema validation, and the output schemas enforce those formats so a future regression fails closed instead of silently leaking a vendor format. This is a contract-tightening change: callers already receiving ISO values are unaffected.

    Affected surface
    catchtable/reservation-detail, catchtable/my-status, catchtable/reserve
    Action required
    No
    Migration guidance
    No action required for callers that already consumed ISO values. The reservation-detail, my-status, and reserve outputs (visit_date, visit_time) are now schema-enforced to ISO YYYY-MM-DD and HH:MM. Callers that defensively parsed compact YYMMDD/YYYYMMDD/HHMM strings can drop that handling; the public contract guarantees ISO.
  24. BreakingRemoved

    Provider IDs moved to globally scoped public-facing identities. Generic Korea-only public-data and implementation-suffix IDs are retired from catalog/discovery surfaces, with gateway fallback aliases kept for legacy callers during the transition.

    APIFuse provider IDs now use public-facing global identities. Korea-scoped government and public-data providers include the country or natural jurisdiction in the provider ID, and implementation suffixes such as `-api`, `-service`, `-realtime`, `-forecast`, `-price`, and `-deals` have been retired from affected provider IDs. Legacy provider IDs remain accepted as gateway fallback aliases for existing callers. Update stored operation paths and generated tool references to the new provider IDs because catalog, metadata, docs, and newly generated tools expose only canonical IDs.

    Affected surface
    law-service/get, law-service/list-legal-sources, law-service/lookup-law-article, law-service/search-appendices-and-forms, law-service/search-committee-decisions, law-service/search-current-laws, law-service/search-law-comparisons, law-service/search-legal-interpretations, law-service/search-legal-resources, law-service/search-legal-terms, law-service/search-ministry-interpretations, law-service/search-precedents, law-service/search-treaties, food-safety/search, drug-safety/lookup, household-waste/info, school-lunch/menu, school-lunch/school-search, delivery-api/carriers, delivery-api/status, delivery-api/track, airkorea-realtime/realtime, kma-forecast/mid-forecast, kma-forecast/short-forecast, kma-forecast/weather-by-address, naver-map-api/bicycle-directions, naver-map-api/car-directions, naver-map-api/geocode, naver-map-api/place, naver-map-api/place-reviews, naver-map-api/search, naver-map-api/transit-directions, naver-map-api/transit-info, naver-map-api/walk-directions, yogiyo-api/confirm-phone, yogiyo-api/find-restaurants, yogiyo-api/order-preview, yogiyo-api/place-order, yogiyo-api/restaurant-full, yogiyo-api/verify-phone, danawa-price/compare-products, danawa-price/get-offers, danawa-price/search-products, ohouse-deals/browse-products, ohouse-deals/card-collection-recommendations, ohouse-deals/comments, ohouse-deals/deal-coupons, ohouse-deals/deal-products, ohouse-deals/exhibition-products, ohouse-deals/product-categories, ohouse-deals/product-coupons, ohouse-deals/product-detail, ohouse-deals/product-options, ohouse-deals/product-questions, ohouse-deals/product-recommendations, ohouse-deals/product-reviews, ohouse-deals/product-shipping, ohouse-deals/product-used-cards, ohouse-deals/products-by-id, ohouse-deals/project-detail, ohouse-deals/project-recommendations, ohouse-deals/promotions, ohouse-deals/search-cards, ohouse-deals/search-products, ohouse-deals/search-trends, ohouse-deals/site-metadata, ohouse-deals/today-deals, daiso-api/browse-catalog, daiso-api/check-pickup-availability, daiso-api/inventory, daiso-api/product-detail, daiso-api/product-reviews, daiso-api/recommend-products, daiso-api/search-products, daiso-api/search-stores, daiso-api/search-trends, daiso-api/site-metadata, daiso-api/store-detail, daiso-api/stores
    Action required
    Yes
    Migration guidance
    Update provider IDs in operation paths. Use korea-national-law, korea-mfds-food-safety, korea-mfds-drug-safety, korea-mois-household-waste, korea-neis-school-meals, korea-parcel-tracking, korea-air-quality, korea-weather, naver-map, yogiyo, danawa, ohouse, and daiso. Operation IDs are unchanged unless already changed by earlier provider-specific contract hardcuts. Legacy provider IDs continue to route at the gateway as compatibility aliases, but new discovery, metadata, examples, and generated tools use canonical IDs only.
  25. BreakingShipped

    Rakuten Travel area search now uses a single directly-searchable area token, and area discovery returns only searchable leaf areas.

    `rakuten-travel/search-hotels-simple` and `rakuten-travel/search-vacant-hotels` now accept one `area` token instead of separate large, middle, small, and detail class-code inputs. The provider still sends Rakuten's upstream class-code parameters internally, but callers must use an `area` value discovered from `get-area-classes`. `rakuten-travel/get-area-classes` now returns a compact `areas[]` list of directly searchable leaf areas. It excludes large areas, middle areas, and small areas that require detail children, and supports `query` plus `limit` for picker/search workflows.

    Affected surface
    rakuten-travel/search-hotels-simple, rakuten-travel/search-vacant-hotels, rakuten-travel/get-area-classes
    Action required
    Yes
    Migration guidance
    Replace large_class_code, middle_class_code, small_class_code, and detail_class_code inputs on rakuten-travel/search-hotels-simple and rakuten-travel/search-vacant-hotels with area values returned by rakuten-travel/get-area-classes, such as japan/akita/tazawa or japan/tokyo/tokyo/F. Update get-area-classes callers to send optional query and limit inputs and read areas[] rows with area and label instead of area_classes or area_tree.
  26. BreakingShipped

    Han River water-level lookups now expose strict APIFuse-standard station, interval, timestamp, water-level, and flow fields instead of HRFCO-shaped names and raw interval path codes.

    `han-river/water-level` is a hard-breaking public contract cleanup. APIFuse still sends HRFCO's required API-key path segment and `waterlevel/list/{10M|1H|1D}/{station}.json` interval path internally, but callers now use semantic snake_case fields and a closed interval enum. The provider also fails closed on HRFCO error envelopes before reading `content`. HRFCO `940` now surfaces as an upstream auth error, and `941` surfaces as an approval or IP/DNS whitelist error.

    Affected surface
    han-river/water-level
    Action required
    Yes
    Migration guidance
    Replace stationCode with station_id and stationName with station_name. Use interval values ten_minutes, one_hour, or one_day instead of HRFCO path codes 10M, 1H, or 1D. Read station.station_id, station.zero_elevation_meters, alert_levels.*_meters, station.forecast_station, water_level.station_id, water_level.interval, water_level.water_level_meters, and water_level.flow_cms instead of station_code, zero_elevation_m, alert_levels.*_m, is_forecast_station, water_level_m, and flow_rate_m3s.
  27. BreakingShipped

    KMA forecast outputs now expose closed normalized weather-condition domains and fail closed on malformed upstream success envelopes.

    The KMA provider now models the data.go.kr success envelope and KMA category codes more strictly at the provider boundary. Successful upstream responses must include the expected envelope, forecast items, known KMA category codes, and valid KMA compact base/forecast timestamps before APIFuse emits normalized ISO timestamps. Unknown KMA category codes, unknown precipitation or sky codes, malformed success envelopes, and missing upstream timestamps now fail closed with `UPSTREAM_SCHEMA_ERROR` instead of fabricating partial weather payloads or silently returning null for unmapped codes.

    Affected surface
    korea-weather/short-forecast, korea-weather/weather-by-address, korea-weather/mid-forecast
    Action required
    Yes
    Migration guidance
    Existing valid KMA short-forecast inputs now use snake_case `grid_x`/`grid_y` plus optional `base_date` and `base_time`; weather-by-address keeps `address` and uses optional `base_date`/`base_time`; mid-forecast uses `region_id` plus optional ISO `tm_fc`. Stop sending legacy camelCase or upstream-style request keys such as `gridX`, `gridY`, `baseDate`, `baseTime`, `regionId`, `tmFc`, `pageNo`, `numOfRows`, or `regId`. Clients that validate or exhaustively switch on short-forecast `precipitation_type` or `sky` should use the documented normalized values: `precipitation_type` is `none`, `rain`, `sleet`, `snow`, or `null`; `sky` is `clear`, `mostly_cloudy`, `overcast`, or `null`. Mid-forecast clients should read relative forecast slots from `day_offset` and normalized temperature fields such as `min_temperature`/`max_temperature` rather than inferred calendar dates or legacy `taMin`/`taMax`-style fields. Treat `UPSTREAM_SCHEMA_ERROR` as an upstream contract drift signal rather than a no-data response.
  28. BreakingShipped

    Food Safety search now uses APIFuse-standard limit and summary fields instead of exposing the data.go.kr numOfRows parameter publicly.

    `korea-mfds-food-safety/search` is a hard-breaking contract standardization. The provider still sends the required data.go.kr `pageNo` and `numOfRows` parameters internally, but callers now use APIFuse semantic field names. Callers should send `query` and optional `limit`. Successful responses now include `summary.limit` and `summary.returned_count` alongside normalized `items[]`; raw data.go.kr envelope fields remain private provider implementation details.

    Affected surface
    korea-mfds-food-safety/search
    Action required
    Yes
    Migration guidance
    Replace numOfRows with limit in korea-mfds-food-safety/search requests. Read returned_count from summary.returned_count, and continue reading normalized product_name, company_name, violation_detail, and registered_date fields from items.
  29. BreakingShipped

    School Lunch now exposes APIFuse-standard NEIS input and meal output field names instead of upstream-shaped NEIS parameters and raw meal codes.

    `korea-neis-school-meals/school-search` and `korea-neis-school-meals/menu` are hard-breaking contract standardizations. Public request fields now use APIFuse snake_case names, while NEIS `pIndex`, `pSize`, `ATPT_OFCDC_SC_CODE`, `SD_SCHUL_CODE`, `MLSV_YMD`, and `MMEAL_SC_CODE` remain private upstream parameters. The menu response now separates dish allergen numbers into `allergen_codes`, exposes meal type as `breakfast`, `lunch`, or `dinner`, and returns calories as numeric `calories_kcal`.

    Affected surface
    korea-neis-school-meals/school-search, korea-neis-school-meals/menu
    Action required
    Yes
    Migration guidance
    For korea-neis-school-meals/school-search, replace educationOfficeCode with education_office_code, schoolName with school_name, pIndex with page, and pSize with limit. For korea-neis-school-meals/menu, replace educationOfficeCode with education_office_code, schoolCode with school_code, mealDate with meal_date, and mealKindCode values 1/2/3 with meal_type values breakfast/lunch/dinner. Read meals[].meal_type and meals[].meal_type_label instead of meal_type_code and meal_type_name, meals[].calories_kcal instead of calories, and meals[].dishes[] objects with name plus allergen_codes instead of raw dish strings.
  30. BreakingShipped

    LH Notice now exposes APIFuse-standard snake_case field names, semantic housing_type values, ISO dates, and an opaque detail_reference follow-up token instead of upstream LH parameter names and tuple codes.

    This release standardizes the `lh-notice` public contract so callers interact with APIFuse-shaped field names rather than LH upstream request parameter names. `lh-notice/list` now accepts semantic `housing_type` values and exact-date filters in ISO `YYYY-MM-DD` format, returns `summary.returned_count` and `summary.total_count`, and reports applied filters under snake_case `filters` fields. Each returned notice includes an opaque `detail_reference` for safe follow-up calls. `lh-notice/detail` now accepts only the `detail_reference` returned by `list`. The upstream LH tuple remains an internal provider mapping detail and is no longer exposed as public input fields. data.go.kr Forbidden and missing-service activation responses now fail closed with typed provider errors instead of silently returning empty results.

    Affected surface
    lh-notice/list, lh-notice/detail
    Action required
    Yes
    Migration guidance
    Replace list inputs panSs, uppAisTpCd, aisTpCd, cnpCdNm, panNm, panNtStDt, clsgDt, and pageSize with status, housing_type, subcategory_code, region, query, posted_date, closing_date, page, and limit. Pass housing_type as one of land, sale_housing, rental_housing, housing_welfare, or commercial instead of LH type codes 01, 05, 06, 13, or 22. Pass posted_date and closing_date as YYYY-MM-DD exact-date filters. Read applied filters from filters.housing_type, filters.subcategory_code, filters.posted_date, and filters.closing_date. Read notices from notice_id, detail_reference, posted_date, closing_date, and detail_url. Use each list item's detail_reference when calling detail. The detail operation now accepts only detail_reference and no longer accepts detailReference, panId, ccrCnntSysDsCd, or splInfTpCd directly. Detail output now returns notice.notice_id, notice.detail_reference, and supply_infos.
  31. BreakingShipped

    Seoul subway, Seoul Bike, AirKorea, and korea-mois-household-waste public contracts now use APIFuse-standard normalized field names instead of upstream-shaped public request and response names.

    These four Korean public-data operations are hard-breaking contract standardizations. APIFuse still sends each upstream's required Seoul Open API or data.go.kr parameter names internally, but callers now use semantic snake_case request fields and consume normalized response fields. Legacy upstream-shaped public fields are rejected by the provider schemas. Update generated SDK calls and any saved operation inputs before invoking these operations.

    Affected surface
    seoul-subway/arrival, seoul-bike/nearby, korea-air-quality/realtime, korea-mois-household-waste/info
    Action required
    Yes
    Migration guidance
    For seoul-subway/arrival, replace stationName with station_name, startIndex with offset, endIndex with limit, and read query plus normalized arrival fields line_id, direction, destination, station_name, arrival_seconds, arrival_message, and previous_station_message. For seoul-bike/nearby, replace lat/lon/radius with latitude/longitude/radius_meters and read station_name, rack_count, available_bike_count, occupancy_percent, latitude, and longitude. For korea-air-quality/realtime, replace stationName with station_name, dataTerm DAILY/MONTH/3MONTH with data_term daily/monthly/three_months, and measuredAt with measured_at. For korea-mois-household-waste/info, replace districtName with district_name.
  32. BreakingShipped

    CatchTable reservation-options and reserve now use reservation_state plus selected_options instead of reservation_choice.

    CatchTable reservation writes now expose intent-level APIFuse fields only. `reservation-options` returns a short-lived opaque `reservation_state`, structured `required_selections`, selectable `selection_value` options, `selected_options` guidance, `continue_with.args`, and `next_action`. `reserve` accepts natural booking inputs plus optional `reservation_state` and `selected_options`. Missing, expired, malformed, tampered, or request-mismatched reservation state fails before upstream calls with `INVALID_RESERVATION_STATE` and refresh guidance. Stale selected options fail before final create with `INVALID_RESERVATION_SELECTION`. The provider replays CatchTable time-slot, reservation-options, holding, and form calls before create, preserves exact requested-time semantics, uses the current CatchTable web build `20260623093850`, and fails closed for payment, deposit, penalty, add-on payment, app-only, and unsupported required course/precaution answer flows.

    Affected surface
    catchtable/reservation-options, catchtable/reserve
    Action required
    Yes
    Migration guidance
    Call `catchtable/reservation-options` for the exact `shop_ref`, `date`, `visit_time`, `person`, and `table_type`. Pass `reservation_state` to `catchtable/reserve`; when `required_selections` is present, pass one `selected_options[]` item with the matching `selection_id` and `selection_value`. Do not pass `reservation_choice`, `reservation_choices`, raw table/menu fields, add-on payloads, or provider request bodies.
  33. BreakingShipped

    Daangn Marketplace search and realty price-history inputs now use APIFuse facade names for availability and transaction filters.

    This release completes a Daangn Marketplace contract standardization pass after the facade hardcut. Search operations now expose `available_only` instead of the upstream-shaped `only_on_sale` query name. Realty complex price history now uses `trade_type` instead of the implementation-shaped `chart_trade_type` selector. The provider still maps those facade names to Daangn's private query parameters internally. Generated public schemas and localized descriptions now avoid the retired input names and raw/upstream wording for the changed surfaces.

    Affected surface
    daangn-marketplace/used-goods-search, daangn-marketplace/realty-search-listings, daangn-marketplace/cars-search, daangn-marketplace/realty-complex-price-history
    Action required
    Yes
    Migration guidance
    Replace `only_on_sale` with `available_only` on `used-goods-search`, `realty-search-listings`, and `cars-search`. Replace `chart_trade_type` with `trade_type` on `realty-complex-price-history`. Opaque ids, canonical URLs, normalized item envelopes, and read-only behavior are unchanged.
  34. BreakingShipped

    Daiso grouped catalog reads no longer expose promotion-specific output branches that were only used by the removed list-promotions operation.

    Daiso grouped catalog read operations keep their typed catalog, recommendation, trend, and metadata outputs. Promotion-specific `promotions` and `banners` fields were tied to the removed `list-promotions` operation and are no longer part of the shared grouped-read output schema.

    Affected surface
    daiso/browse-catalog, daiso/recommend-products, daiso/search-trends, daiso/site-metadata
    Action required
    Yes
    Migration guidance
    If you reused the shared Daiso grouped-read output schema, remove handling for promotion-specific promotions and banners fields from browse-catalog, recommend-products, search-trends, and site-metadata consumers. Continue using each operation's catalog, recommendation, trend, or metadata fields for its primary result shape.
  35. BreakingRemoved

    Daiso list-promotions has been removed because the upstream promotion and banner surfaces no longer produce stable customer-visible rows.

    Daiso `list-promotions` has been removed from the public provider contract. The live upstream promotion/banner surfaces currently return empty normalized display rows, so keeping a public operation and status signal for that surface produces misleading provider health noise. The remaining Daiso catalog grouped operations keep typed catalog, trend, recommendation, and metadata outputs. Promotion-specific `promotions` and `banners` fields are no longer part of the Daiso grouped-read output schema.

    Affected surface
    daiso/list-promotions
    Action required
    Yes
    Migration guidance
    Stop calling daiso/list-promotions. Use search-products, browse-catalog, search-trends, recommend-products, site-metadata, or store/search operations depending on the user intent. The shared Daiso grouped-read schema no longer includes the list-promotions operation branch or promotions/banners output fields.
  36. BreakingShipped

    Drug Safety lookup now exposes APIFuse-standard input and output field names instead of MFDS/data.go.kr upstream parameter and response names.

    `korea-mfds-drug-safety/lookup` is a hard-breaking contract standardization. The operation no longer exposes upstream-shaped public input fields (`itemName`, `pageNo`, `numOfRows`) or upstream-shaped output fields (`item_name`, `company_name`, `how_to_use`, `item_seq`, `page_no`, or `num_of_rows`). Callers should send `query`, `page`, and `limit`, and consume `items[]` plus `summary` using the normalized APIFuse field names.

    Affected surface
    korea-mfds-drug-safety/lookup
    Action required
    Yes
    Migration guidance
    Replace itemName with query, pageNo with page, and numOfRows with limit. Read normalized medicine fields such as medicine_name, manufacturer_name, usage, drug_id, and summary instead of item_name, company_name, how_to_use, item_seq, page_no, and num_of_rows.
  37. BreakingRemoved

    Law-service removes the previous search/detail/compare/terms operations and replaces them with task-focused Korean legal search, lookup, and comparison operations.

    The korea-national-law provider now exposes Korean legal search, source listing, focused search operations, legal-resource detail lookup, law comparison search, legal-term search, and law article lookup. The previous `search`, `detail`, `compare`, and `terms` operations have been removed, so callers must move to the new operation IDs and snake_case request fields.

    Affected surface
    korea-national-law/search, korea-national-law/detail, korea-national-law/compare, korea-national-law/terms
    Action required
    Yes
    Migration guidance
    Replace korea-national-law/search with search-legal-resources or a focused search-* operation, replace korea-national-law/detail with get or lookup-law-article, replace korea-national-law/terms with search-legal-terms plus get for term detail, and replace korea-national-law/compare with search-law-comparisons using snake_case request fields such as law_name and comparison_type. The old law, article, compare, and term request shapes are retired.
  38. BreakingShipped

    K-Startup announcements and business-info now expose APIFuse-standard input fields and items/summary response envelopes instead of upstream-shaped K-Startup parameter and envelope names.

    `kstartup/announcements` and `kstartup/business-info` are hard-breaking contract standardizations. The provider still sends K-Startup's required `returnType=json`, `page`, and `perPage` parameters internally, but callers now use APIFuse semantic field names. Successful list responses now return normalized `items[]` plus `summary` metadata including `page`, `limit`, `returned_count`, and the public filters used for the request. The previous public `data` array and raw `query` parameter echo are no longer part of the provider contract.

    Affected surface
    kstartup/announcements, kstartup/business-info
    Action required
    Yes
    Migration guidance
    For announcements, replace perPage with limit, biz_pbanc_nm with query, supt_regin with support_region, supt_biz_clsfc with support_field, pbanc_rcpt_bgng_dt with application_start_date in YYYY-MM-DD format, pbanc_rcpt_end_dt with application_end_date in YYYY-MM-DD format, aply_trgt with target_audience, biz_enyy with startup_age, biz_trgt_age with target_age, rcrt_prgs_yn Y/N with recruitment_status open/closed, and intg_pbanc_yn Y/N with integrated_announcement true/false. For business-info, replace perPage with limit, biz_yr with year, biz_category_cd with category_code, and supt_biz_titl_nm with query. Read results from items and summary instead of data and query.
  39. BreakingShipped

    Naver Blog search now exposes APIFuse-standard input and output field names instead of Naver upstream parameter and response names.

    `naver-blog/search` is a hard-breaking contract standardization. The operation no longer exposes upstream-shaped public input fields (`display`, `start`, `sort`) or upstream-shaped output fields (`link`, `bloggername`, `bloggerlink`, `postdate`, `meta`, or `lastBuildDate`). Callers should send `limit`, `offset`, and `sort_by`, and consume `items[]` plus `summary` using the normalized APIFuse field names.

    Affected surface
    naver-blog/search
    Action required
    Yes
    Migration guidance
    Replace display with limit, start with offset, sort with sort_by values relevance/date, and read normalized blog fields such as url, blogger_name, blogger_url, published_date, and summary.
  40. BreakingShipped

    Naver Flight search operations now use the APIFuse-standard snake_case public contract for request and response fields.

    This is a hard-breaking contract standardization. Naver Flight keeps the same operation ids, upstream behavior, anonymous NNB acquisition, and search semantics, but the public API now follows APIFuse snake_case naming. The provider still uses Naver's upstream camelCase fields internally where required by the flight API. Those upstream names are no longer exposed as public request or response fields.

    Affected surface
    naver-flight/search-flights, naver-flight/search-oneway-flights
    Action required
    Yes
    Migration guidance
    Replace departure/arrival with departure_airport/arrival_airport, departureDate/returnDate with departure_date/return_date, and maxResults with limit. Update response readers from camelCase fields such as tripType, returnedCount, totalKnownCombinations, lowestGeneralFare, lowestCardFare, actionHint, airlineCode, depAirport, durationMin, generalFare, bestCardFare, curationTags, and carbonEmission to the new snake_case names.
  41. BreakingShipped

    Naver Map now exposes APIFuse-standard snake_case public field names instead of mixed-case or upstream-shaped field names.

    `naver-map` is a hard-breaking contract standardization across public map, place, review, transit, and directions operations. The provider no longer exposes upstream-shaped public fields such as `size`, `car_type`, `fuel_type`, `roadAddress`, `naverMapUrl`, `startPoint`, `endPoint`, `taxiFare`, `tollFare`, `durationSeconds`, or `walkingDurationSeconds`. Callers should send the normalized request fields and consume snake_case response fields from the generated APIFuse schemas.

    Affected surface
    naver-map/search, naver-map/geocode, naver-map/place, naver-map/place-reviews, naver-map/transit-info, naver-map/car-directions, naver-map/transit-directions, naver-map/walk-directions, naver-map/bicycle-directions
    Action required
    Yes
    Migration guidance
    Replace search and place-reviews size with limit; replace car-directions car_type/fuel_type with vehicle_type_code/fuel_type_code; read snake_case response fields such as road_address, distance_meters, naver_map_url, has_next, source_totals, start_point, end_point, interval_minutes, duration_seconds, toll_fare, taxi_fare, start_name, end_name, transfer_count, and walking_duration_seconds.
  42. BreakingShipped

    Naver News search now exposes APIFuse-standard input and output field names instead of Naver upstream parameter and response names.

    `naver-news/search` is a hard-breaking contract standardization. The operation no longer exposes upstream-shaped public input fields (`display`, `start`, `sort`) or upstream-shaped output fields (`originallink`, `link`, `description`, `pubDate`, `pubDateIso`, `meta`, or `lastBuildDate`). Callers should send `limit`, `offset`, and `sort_by`, and consume `items[]` plus `summary` using the normalized APIFuse field names.

    Affected surface
    naver-news/search
    Action required
    Yes
    Migration guidance
    Replace display with limit, start with offset, sort with sort_by values relevance/date, and read normalized article fields such as original_url, url, summary, published_at, published_at_text, plus top-level summary metadata.
  43. BreakingRemoved

    Removed low-level Daangn realty operations superseded by the hardcut facade contract.

    This hard-breaking cleanup removes legacy low-level Daangn realty operations that were superseded by the facade contract introduced in `daangn-marketplace-contract-hardcut`.

    Affected surface
    daangn-marketplace/realty-search, daangn-marketplace/realty-detail, daangn-marketplace/realty-region-search, daangn-marketplace/realty-region, daangn-marketplace/realty-reverse-geocode, daangn-marketplace/realty-count, daangn-marketplace/realty-clusters, daangn-marketplace/realty-articles-by-cluster, daangn-marketplace/realty-article-detail, daangn-marketplace/realty-complex-ranking, daangn-marketplace/realty-complex-list, daangn-marketplace/realty-nearby-complexes, daangn-marketplace/realty-complex-area-groups, daangn-marketplace/realty-complex-price-chart
    Action required
    Yes
    Migration guidance
    Use realty-search-listings and realty-listing-detail for listings; realty-search-regions for region discovery; realty-search-complexes, realty-complex-detail, realty-complex-listings, and realty-complex-price-history for complex flows. Follow-up ids are now APIFuse opaque id values returned by search/list operations.
  44. BreakingShipped

    Daangn Marketplace public contracts hardcut upstream-shaped field names, Relay/raw identifiers, source metadata, and low-level realty mechanics in favor of facade operations, opaque APIFuse ids, canonical URLs, and product envelopes.

    This release is a breaking hardcut of the Daangn Marketplace public provider contract. The provider no longer exposes Relay ids, original upstream ids, raw region/article/cluster/complex parameter names, GraphQL source branch names, or raw transaction arrays in public schemas. Public `id` fields are APIFuse-owned opaque values intended for follow-up calls. Realty low-level operations were removed from the public operation set and replaced by facade operations: - `realty-search-regions` - `realty-search-listings` - `realty-listing-detail` - `realty-search-complexes` - `realty-complex-detail` - `realty-complex-listings` - `realty-complex-price-history` Search/list responses now return `items`, `summary.returned_count`, optional `summary.query`, optional `summary.region`, optional `summary.next_cursor`, and optional `canonical_url`. Detail responses return `item` and optional `canonical_url`.

    Affected surface
    daangn-marketplace/used-goods-search, daangn-marketplace/used-goods-detail, daangn-marketplace/jobs-search, daangn-marketplace/jobs-detail, daangn-marketplace/cars-search, daangn-marketplace/cars-detail, daangn-marketplace/realty-search-regions, daangn-marketplace/realty-search-listings, daangn-marketplace/realty-listing-detail, daangn-marketplace/realty-search-complexes, daangn-marketplace/realty-complex-detail, daangn-marketplace/realty-complex-listings, daangn-marketplace/realty-complex-price-history
    Action required
    Yes
    Migration guidance
    Replace raw realty operation calls with facade operations. Use realty-search-listings and realty-listing-detail for listings; realty-search-regions for region discovery; realty-search-complexes, realty-complex-detail, realty-complex-listings, and realty-complex-price-history for complex flows. Follow-up ids are now APIFuse opaque id values returned by search/list operations. Use canonical_url instead of source_url, summary.returned_count instead of ad hoc count/source fields, and domain branches such as realty/job/car/used_goods instead of metadata. Jobs search no longer accepts only_on_sale.
  45. BreakingShipped

    Daangn realty complex price history now accepts REGISTERED_OWNER as a transaction ownership enum value when upstream exposes it on sale transaction rows.

    This change tracks an additive enum value in Daangn's realty complex price-history GraphQL response. `realty-complex-price-history` sale transaction rows may now return `ownership: "REGISTERED_OWNER"` in addition to `PRE_SALE_RIGHT`. The provider preserves the value in the normalized `buy_transactions[].ownership` field instead of treating the upstream response as a schema error. The change is response-only. Existing request inputs, opaque complex ids, chart point fields, and transaction amount fields are unchanged.

    Affected surface
    daangn-marketplace/realty-complex-price-history
    Action required
    No
    Migration guidance
    No input changes are required. Clients that exhaustively switch on buy_transactions[].ownership should add REGISTERED_OWNER alongside PRE_SALE_RIGHT. The field remains optional and existing PRE_SALE_RIGHT handling is unchanged.
  46. BreakingShipped

    Daiso provider operations now use a hard-breaking canonical APIFuse contract with typed product, store, pickup availability, catalog, trend, recommendation, and metadata outputs.

    This is a hard-breaking cleanup. Daiso no longer exposes duplicate compatibility operations or grouped endpoint summaries as the stable public API. `source_payloads` remains optional diagnostic evidence for supported operations, but callers should depend on normalized typed fields.

    Affected surface
    daiso/browse-catalog, daiso/check-pickup-availability, daiso/inventory, daiso/product-detail, daiso/product-reviews, daiso/recommend-products, daiso/search-products, daiso/search-stores, daiso/search-trends, daiso/site-metadata, daiso/store-detail, daiso/stores
    Action required
    Yes
    Migration guidance
    Replace removed operation ids with canonical kebab-case ids. Use search-products instead of products/search_products, product-detail instead of get_product_detail/product_detail, product-reviews instead of get_product_reviews/product_reviews, store-detail instead of get_store_detail/store_detail, check-pickup-availability instead of direct pickup inventory/location/product availability operations, search-trends instead of get_search_trends/search_trends, recommend-products instead of get_recommendations/recommend_products, and site-metadata instead of get_site_metadata/site_metadata. Replace page_size with limit and review sort with sort_by recommended/latest.
  47. BreakingRemoved

    Removed duplicate legacy and underscore Daiso operation ids in favor of the canonical kebab-case Daiso contract.

    This hard-breaking cleanup removes legacy aliases and upstream-shaped Daiso operation ids so the public contract has one canonical name per Daiso capability.

    Affected surface
    daiso/browse_catalog, daiso/get_product_availability, daiso/get_product_detail, daiso/get_product_reviews, daiso/get_promotions, daiso/get_recommendations, daiso/get_search_trends, daiso/get_site_metadata, daiso/get_store_detail, daiso/get_store_inventory, daiso/get_store_product_location, daiso/products, daiso/search_pickup_stores, daiso/search_products, daiso/search_stores
    Action required
    Yes
    Migration guidance
    Use search-products, product-detail, product-reviews, search-stores, store-detail, check-pickup-availability, browse-catalog, search-trends, recommend-products, site-metadata, and list-promotions. The stores and inventory operations remain available.
  48. BreakingRemoved

    Ohouse public operation ids and product contracts now use APIFuse product-facing names instead of upstream-shaped operation and field names.

    Ohouse is now a product-facing APIFuse provider contract rather than a public mirror of upstream endpoint names. Internal handlers still map to Ohouse `goodsId`, `productionId`, affect parameters, and exhibition section identifiers as needed, but callers should only use semantic APIFuse fields. Normal successful outputs, including `today-deals`, no longer include raw upstream request URLs by default. The removed `today_deals` operation alias and its MCP tool alias `ohouse_deals__today_deals_legacy` are not retained; use `today-deals` / `ohouse_deals__today_deals`. Today Deals product rows now expose `product_id` instead of the previous `id` field. Product reviews now expose `summary.average_rating`, `summary.total_count`, and `summary.rating_counts[]` instead of `star_counts.count_for_N`. Coupon lookup is split into product and deal operations, exhibition products use `section`, and shipping metadata uses `method` / `service_level`.

    Affected surface
    ohouse/today_deals, ohouse/today-deals, ohouse/search_products, ohouse/browse_store_category, ohouse/browse_product_categories, ohouse/get_product_detail, ohouse/get_products_by_ids, ohouse/get_deal_products, ohouse/get_exhibition_section_items, ohouse/get_product_options, ohouse/get_product_delivery, ohouse/get_product_coupons, ohouse/get_product_recommendations, ohouse/get_product_reviews, ohouse/get_product_questions, ohouse/get_product_used_cards, ohouse/search_cards, ohouse/get_comments, ohouse/get_project_detail, ohouse/get_project_recommendations, ohouse/get_card_collection_recommendations, ohouse/get_promotions, ohouse/get_search_trends, ohouse/get_site_metadata
    Action required
    Yes
    Migration guidance
    Replace old snake_case Ohouse operation ids with the new kebab-case ids: `search_products` to `search-products`, `browse_store_category` to `browse-products`, `browse_product_categories` to `product-categories`, `get_product_detail` to `product-detail`, `get_products_by_ids` to `products-by-id`, `get_deal_products` to `deal-products`, `get_exhibition_section_items` to `exhibition-products`, `get_product_options` to `product-options`, `get_product_delivery` to `product-shipping`, `get_product_coupons` product branch to `product-coupons`, `get_product_coupons` deal branch to `deal-coupons`, `get_product_recommendations` to `product-recommendations`, `get_product_reviews` to `product-reviews`, `get_product_questions` to `product-questions`, `get_product_used_cards` to `product-used-cards`, `search_cards` to `search-cards`, `get_comments` to `comments`, `get_project_detail` to `project-detail`, `get_project_recommendations` to `project-recommendations`, `get_card_collection_recommendations` to `card-collection-recommendations`, `get_promotions` to `promotions`, `get_search_trends` to `search-trends`, and `get_site_metadata` to `site-metadata`. Stop calling `today_deals`; use `today-deals`, and update `today-deals` response consumers to read product rows from `product_id` while no longer depending on removed `source_url` / `source_api_url` fields. MCP clients that cached the removed Today Deals alias tool `ohouse_deals__today_deals_legacy` must switch to the retained canonical Today Deals tool `ohouse_deals__today_deals`. Replace public product inputs `goods_id` and `production_id` with `product_id`. Remove search/browse affect fields from requests; APIFuse sets required Ohouse ceremony values privately. Replace product coupon `{ target_type: "product", id }` with `{ product_id }`, and deal coupon `{ target_type: "deal", id }` with `deal-coupons` `{ deal_id }`. Replace exhibition `{ detail_id, section_id }` with semantic `{ section }`. Read shipping from `shipping.method` and `shipping.service_level` instead of method/service code fields. Read product rows from `product_id`, review counts from `summary.rating_counts[]`, question totals from `summary.total_count`, and stop depending on `source_url` or `source_api_url` in normal outputs.
  49. BreakingShipped

    CatchTable search, shop, my-status, and register-waiting now use the normalized APIFuse facade contract.

    CatchTable read operations now expose APIFuse-standard snake_case field names instead of upstream-shaped camelCase names on the public contract. Waiting discovery signals are grouped under `waiting_discovery_hint` so callers treat them as queue-discovery hints rather than registration proof. CatchTable `waiting-info` now isolates upstream table/person-option ceremony behind normalized discovery fields. Use `waiting_tables[].table_ref` only as display/diagnostic context and choose `waiting_choices[].waiting_choice` for registration; `person_option_summary` replaces the previous raw `person_options` array. CatchTable `register-waiting` now uses the opaque `waiting_choice` path as the recommended public contract. Raw upstream ceremony fields such as `table_id`, `person_options`, and `order.order_line_items` are no longer accepted by the public schema in Development stage. Order-required waiting shops should use simple `menu_choice` tokens returned by `waiting-menus`; complex menu options still fail closed when they cannot be represented safely.

    Affected surface
    catchtable/search, catchtable/shop, catchtable/my-status, catchtable/waiting-info, catchtable/register-waiting
    Action required
    Yes
    Migration guidance
    Replace CatchTable search/shop output reads from camelCase fields such as `shopRef`, `shopName`, `foodKind`, `avgRating`, `reviewCount`, `waitingAvailable`, and `waitingCount` with `shop_ref`, `shop_name`, `food_kind`, `average_rating`, `review_count`, and `waiting_discovery_hint`. Replace my-status reads from `activeWaitings`, `reservationRef`, `waitingRef`, `shopName`, `visitDate`, `visitTime`, `personCount`, and `waitingOrder` with `active_waitings`, `reservation_ref`, `waiting_ref`, `shop_name`, `visit_date`, `visit_time`, `person_count`, and `waiting_order`. For waiting-info, read `waiting_tables[].table_ref` and `waiting_tables[].label` instead of `tables[].table_id` and `tables[].name`, and read `person_option_summary` instead of raw `person_options`. Call `register-waiting` with `waiting_choice` and optional `menu_choices`; do not pass raw `table_id`, `person_options`, or `order.order_line_items`.
  50. BreakingShipped

    Daangn realty operations now accept wider upstream enum sets for article status, building type, and management cost fields; the complex detail query migrates from ComplexIdQuery to ComplexDetailPageQuery; region search tolerates partial parent region shells; and building_type_label now resolves correctly.

    This change tracks upstream schema drift in Daangn's realty GraphQL surface. All modifications are additive except the `source` rename on complex listing articles. **Article status**: The `article_status` field now accepts `RESERVED` and `TRADED` alongside the existing `ON_GOING`, matching the current upstream enum. **Building types**: `MIXED_USE` and `ETC` are added to `building_type` across realty complex operations. The `building_type_label` field now maps these values using the correct Korean labels (`주상복합`, `기타`), fixing a prior bug where complex summary and complex detail were accidentally resolving building type labels through the sales type labels map. **Management cost**: `charge_type` expands to include `ETC` and `UNAVAILABLE`. The `unavailable_reason` sub-field gains `SINGLE_HOUSE` and `UNREGISTERED_OR_NEW`. The `calculation_period` sub-field gains `LAST_MONTH`, `AVG_1_YEAR`, and `ETC`. The `etc_charge_basis` sub-field gains several new upstream values covering individual meter, regulation-based, area/usage, and estimated basis variants. **Complex detail query migration**: The provider now fetches complex detail via `ComplexDetailPageQuery` instead of `ComplexIdQuery`, removing the now-unused `checkinRegionIds` parameter. Articles returned from `realty-complex-listings` carry `source: ComplexDetailPageQuery.articles` instead of `source: ComplexIdQuery.articles`. **Region search parent shells**: `realty-search` now handles partial parent region records that contain only an `id` field, returning them with available fields populated and omitting absent ones instead of raising an upstream schema error.

    Affected surface
    daangn-marketplace/realty-search-regions, daangn-marketplace/realty-search-listings, daangn-marketplace/realty-listing-detail, daangn-marketplace/realty-search-complexes, daangn-marketplace/realty-complex-detail, daangn-marketplace/realty-complex-listings, daangn-marketplace/realty-complex-price-history
    Action required
    No
    Migration guidance
    No input changes are required. The article_status field may now return RESERVED or TRADED in addition to ON_GOING. The building_type field may now return MIXED_USE or ETC; building_type_label resolves these correctly. Management cost charge_type may return ETC or UNAVAILABLE in addition to FIXED. Articles returned from complex listings will carry source ComplexDetailPageQuery.articles instead of ComplexIdQuery.articles. Callers that branched on the old source string should update to the new value.
  51. BreakingShipped

    CatchTable reserve now exposes only simple booking fields plus reservation_choice for table/menu-specific slots.

    CatchTable unauthenticated availability now marks reservation option inspection as authentication-required instead of implying that create is known safe from time slots alone. CatchTable reserve now rejects raw table/menu/add-on inputs at schema validation and keeps the public input to `shop_ref`, `date`, `time`, `person`, and optional `reservation_choice`. Ambiguous table/menu choices are resolved through `reservation-options` choice tokens before holding/create side effects, and `PAYMENT_REQUIRED` detection covers deposit, charge amount, penalty, add-on payment, and reservation payment form fields.

    Affected surface
    catchtable/availability, catchtable/reserve
    Action required
    No
    Migration guidance
    Call authenticated `catchtable/reservation-options` before `catchtable/reserve` when a shop/time may expose table, menu, add-on, deposit, penalty, or app-only requirements. Pass the selected `reservation_choices[].reservation_choice` back to `reserve` as `reservation_choice`; do not pass raw `table_type`, `menu_set_seq`, `selected_menu_items`, or `selected_addon_items` to `reserve`.
  52. BreakingRemoved

    KakaoMap provider operation IDs now use the shorter provider id `kakaomap` instead of `kakaomap-api`.

    This renames the public KakaoMap provider id to match the existing provider folder and product-facing name. The affected operations keep the same operation ids and request/response contracts; only the provider id segment changes.

    Affected surface
    kakaomap-api/bicycle-directions, kakaomap-api/car-directions, kakaomap-api/geocode, kakaomap-api/place, kakaomap-api/place-reviews, kakaomap-api/search, kakaomap-api/transit-directions, kakaomap-api/transit-info, kakaomap-api/walk-directions
    Action required
    Yes
    Migration guidance
    Update callers from `/v1/kakaomap-api/<operation>` or `kakaomap-api/<operation>` to `/v1/kakaomap/<operation>` or `kakaomap/<operation>`. Operation payload schemas, auth mode, and behavior are unchanged.
  53. BreakingShipped

    Naver Shopping search now exposes APIFuse-standard input and output field names instead of Naver upstream parameter and response names.

    `naver-shopping/search` is a hard-breaking contract standardization. The operation no longer exposes upstream-shaped public input fields (`display`, `start`, `sort`) or upstream-shaped output fields (`link`, `image`, `lprice`, `hprice`, `mallName`, `productId`, `productType`, `category1` through `category4`, `meta`, or `lastBuildDate`). Callers should send `limit`, `offset`, and `sort_by`, and consume `items[]` plus `summary` using the normalized APIFuse field names.

    Affected surface
    naver-shopping/search
    Action required
    Yes
    Migration guidance
    Replace display with limit, start with offset, sort with sort_by values relevance/date/price_asc/price_desc, and read normalized product fields such as url, image_url, lowest_price, highest_price, mall_name, product_id, product_type_code, category_path, and summary.
  54. BreakingShipped

    Provider public date and time fields now use ISO/RFC-style formats instead of compact upstream encodings.

    This standardizes provider-facing temporal contracts at the APIFuse boundary while preserving compact upstream formats internally. Regression coverage verifies representative input conversion to upstream compact parameters and output conversion back to ISO values for the migrated providers.

    Affected surface
    korea-mfds-food-safety/search, korea-weather/short-forecast, korea-weather/weather-by-address, korea-weather/mid-forecast, kstartup/announcements, korea-national-law/search, korea-national-law/detail, naver-blog/search, naver-flight/search-flights, naver-flight/search-oneway-flights, korea-neis-school-meals/school-search, korea-neis-school-meals/menu
    Action required
    Yes
    Migration guidance
    Update callers to send KMA baseDate and School Lunch mealDate as YYYY-MM-DD, KMA baseTime as HH:mm, KMA tmFc as an ISO 8601 datetime with timezone, and K-Startup announcement date filters as YYYY-MM-DD. Update response consumers to read Food Safety registered_date, KMA forecast date/time, K-Startup application dates, Law date fields, Naver Blog postdate, Naver Flight segment date, and School Lunch founded_date/meal_date as ISO YYYY-MM-DD or HH:mm rather than compact upstream strings.
  55. BreakingShipped

    Daangn realty operations now use the current realty GraphQL surface, return canonical realty article URLs, declare the current map filter contract, and expose normalized Korean realty labels plus richer article quality fields for easier client filtering and display

    This change restores Daangn realty reads after the upstream realty route moved away from the legacy Remix _data contract. The provider now resolves the region, fetches map clusters and article cards through Daangn realty GraphQL, applies optional keywords over normalized article text and Korean labels, and returns canonical `https://realty.daangn.com/articles/<id>` URLs The public detail operation keeps the existing URL input shape but uses GraphQL for canonical realty article URLs. The response adds caller-friendly realty metadata labels such as `sales_type_label`, `trade_type_label`, and `writer_type_label` so clients do not have to display vendor enums like `OPEN_ONE_ROOM`, `OFFICETEL`, `MONTH`, or `BROKER` The richer article operations now preserve high-value fields that Daangn already exposes in the GraphQL response, including annual-rent amounts, floor ambiguity, management-cost unavailable/calculation details, option labels, parking availability, move-in date, building orientation labels, subway stations, object-shaped verification states, direct-user writer type, writer summary, and engagement counters. Realty map filter inputs also declare the current upstream UI enum set for `sales_types`, `trade_types`, `floor`, `options`, `building_approval_date`, and `deal_type`, plus numeric/range filters for rent, sale price, area, household count, and parking density rather than accepting undocumented arbitrary strings

    Affected surface
    daangn-marketplace/realty-search-regions, daangn-marketplace/realty-search-listings, daangn-marketplace/realty-listing-detail, daangn-marketplace/realty-search-complexes, daangn-marketplace/realty-complex-detail, daangn-marketplace/realty-complex-listings, daangn-marketplace/realty-complex-price-history
    Action required
    No
    Migration guidance
    Existing callers can keep using region, query, limit, and URL inputs. Realty search no longer depends on Daangn's retired www.daangn.com realty _data route. Clients that displayed raw sales_type, trade_type, writer_type, option, or orientation enums should prefer the *_label fields when present, while keeping enum fields for machine logic. The map filter inputs now declare the current realty UI sales_types, trade_types, floor, options, building_approval_date, deal_type, amount range, area, household count, and parking-per-household values instead of accepting undocumented arbitrary strings, so callers should pass only documented filter enum values
  56. BreakingShipped

    CatchTable availability, reservation, and waiting flows now expose opaque choice tokens and machine-readable next actions so clients can avoid assembling raw upstream table/menu/order payloads.

    This change converts vendor-specific CatchTable ceremony into a caller-friendly facade contract. Availability now keeps the existing `time_slots` output while adding selectable reservation choices, payment/create-support metadata, and `next_action`/`action_hint` guidance. Reservation and waiting write operations verify signed opaque choices and revalidate them against current upstream state before any hold/create side effect. The same provider-SDK choice-token helper is available for future complex facades such as Yogiyo menu/order choices and Modu Parking payment/session choices, but this release only changes CatchTable public operation contracts.

    Affected surface
    catchtable/availability, catchtable/reserve, catchtable/waiting-info, catchtable/waiting-menus, catchtable/register-waiting
    Action required
    No
    Migration guidance
    CatchTable reservation callers should use `reservation_choices[].reservation_choice` from `reservation-options`, then pass that opaque token back to `reserve`. Waiting callers should use `waiting_choice` from `waiting-info` and `menu_choice` values from `waiting-menus`, then pass those opaque tokens back to `register-waiting`. Raw table/menu reservation inputs are not part of the public reserve contract.
  57. BreakingShipped

    Modu Parking start-payment now exposes closed, redacted per-gateway diagnostics when only some requested payment gateways fail.

    Modu Parking multi-gateway payment URL creation can succeed for one gateway while another requested gateway fails. The output contract now documents the partial-success diagnostics that the provider already returns: `failed_payment_gateways` lists failed known gateways, and `payment_gateway_errors` carries redacted, per-gateway diagnostics without requiring every gateway key. This is a contract-clarity and schema-correctness update for partial successes. It does not require callers that only consume the successful `payment_url` and `pg_type` fields to change behavior.

    Affected surface
    modu-parking/start-payment
    Action required
    No
    Migration guidance
    Existing successful callers can continue reading payment_url and pg_type. Clients that inspect partial payment gateway failures should treat payment_gateway_errors as an optional object keyed only by failed known gateways, and failed_payment_gateways as the matching optional list. Unsupported gateway keys remain rejected.
  58. BreakingShipped

    Yogiyo restaurant results now preserve upstream delivery-time display ranges and no longer expose zero-only pickup minutes as a real ETA.

    Yogiyo discovery rows can return `minimum_pickup_minutes: 0` while carrying the real customer-facing ETA in `estimated_delivery_time` such as `18~33분`. The provider now preserves that display text, derives comparable min/max minute fields from it, and omits ETA fields when the only evidence is a zero placeholder.

    Affected surface
    yogiyo/find-restaurants, yogiyo/restaurant-full
    Action required
    No
    Migration guidance
    Existing clients can continue using numeric ETA fields. For user-facing Yogiyo delivery-time answers, prefer `estimated_delivery_time` when present; treat absent ETA fields as unknown instead of assuming zero minutes.
  59. BreakingShipped

    Yogiyo restaurant search, order preview, and place order now harden address geocoding failures and normalize delivery pricing fields without exposing raw caller addresses.

    Yogiyo address geocoding now fails closed when upstream returns no candidates instead of treating the caller's location hint as a resolved address. Public GEOCODE_FAILED messages are generic and do not echo the raw address value supplied by the caller. Restaurant search, order preview, and place order also normalize delivery-pricing display semantics from current Yogiyo tier data. The base `delivery_fee` follows the lowest order-amount tier rather than a later free-delivery tier, while threshold-specific details remain available through `delivery_fee_tiers` and `free_delivery_threshold`.

    Affected surface
    yogiyo/find-restaurants, yogiyo/order-preview, yogiyo/place-order
    Action required
    No
    Migration guidance
    Existing valid callers can keep using the same inputs. Clients should handle GEOCODE_FAILED as a sanitized validation error and should read delivery_fee as the base fee for the lowest order-amount tier; free_delivery_threshold and delivery_fee_tiers remain available for threshold-specific display.
  60. BreakingShipped

    LH notice list responses now expose the official detail tuple, and detail responses return the tuple reference instead of fabricated notice summary fields.

    The LH detail endpoint returns supply-specific datasets such as `dsSplScdl`, `dsSbd`, and `dsAhflInfo`, but it does not reliably return the full public notice summary exposed by the list endpoint. APIFuse now makes the list-to-detail contract explicit. `lh-notice/list` includes the official `ccr_cnnt_sys_ds_cd` and `spl_inf_tp_cd` tuple fields needed for follow-up detail calls. `lh-notice/detail` returns the requested tuple reference plus the upstream supply detail rows, and no longer synthesizes title, category, region, dates, or detail URL from attachment metadata or secondary list scans.

    Affected surface
    lh-notice/list, lh-notice/detail
    Action required
    Yes
    Migration guidance
    Callers should read notice_id, ccr_cnnt_sys_ds_cd, and spl_inf_tp_cd from the selected lh-notice/list item, then call lh-notice/detail with panId=notice_id, ccrCnntSysDsCd=ccr_cnnt_sys_ds_cd, and splInfTpCd=spl_inf_tp_cd. Callers that need title, status, category, region, posted_date, closing_date, or detail_url should keep those fields from the selected list item. lh-notice/detail.notice now contains only notice_id, ccr_cnnt_sys_ds_cd, and spl_inf_tp_cd because the upstream LH detail endpoint does not reliably return the public notice summary.
  61. BreakingShipped

    Daiso grouped read operations now expose an optional branch fan-out control for caller-managed lightweight checks while preserving default full grouped-read behavior.

    Daiso grouped catalog, trend, recommendation, and site metadata operations now accept `include_optional_branches`. The default remains `true`, preserving the previous behavior of attempting optional HAR-observed endpoint branches and reporting partial failures in metadata. Provider health probes continue exercising the default branch set, including optional branches, and reduce probe pressure by using a longer grouped-operation cadence rather than hiding optional-branch failures.

    Affected surface
    daiso/browse-catalog, daiso/search-trends, daiso/recommend-products, daiso/site-metadata
    Action required
    No
    Migration guidance
    Existing callers can continue using the same inputs and default behavior. To reduce optional endpoint fan-out for caller-managed lightweight checks, pass `include_optional_branches: false`; omit it or set it to true to keep the previous full grouped-read behavior.
  62. BreakingShipped

    Yogiyo restaurant menus, order preview, and order submission now follow guest mobile-web visible ordering rules, display-first pricing, blockers, and fixed NaverPay/safety-number semantics.

    Yogiyo menu and checkout responses now make guest mobile-web-visible ordering rules, pricing, and preconditions explicit before payment handoff. `restaurant-full` filters menu sections the web frontend does not show for normal ordering and annotates web-unavailable menu/option choices. `order-preview` returns a UI-ready `display` summary, structured `price_breakdown`, machine-readable `price_lines`, `blockers`, `can_place_order`, and fixed payment/safety-number flags. `order-preview` and `place-order` enforce guest web frontend blockers for hidden menu sections, disposable item availability, one-time cup deposit choices, and stock over-selection. `place-order` no longer accepts a public `safety_number` toggle. APIFuse submits guest Yogiyo orders with safety number enabled and returns a NaverPay payment URL plus the same display-first pricing details for the submitted cart.

    Affected surface
    yogiyo/restaurant-full, yogiyo/order-preview, yogiyo/place-order
    Action required
    Yes
    Migration guidance
    Yogiyo clients should refresh restaurant-full before constructing carts, use only visible menu_sections, and avoid items/options with web_order_unavailable_reason. Show order-preview.display to users before calling place-order, check can_place_order=true and blockers=[] before submission, and treat price_breakdown/price_lines as validation details rather than the primary UI. Remove safety_number from place-order requests; guest remote orders always use safety number and NaverPay. place-order responses now include display, payment_method=NAVERPAY, payment_method_label, price_breakdown, and price_lines alongside payment_url.
  63. BreakingShipped

    Yogiyo restaurant search and detail now retain live shopyo response fields and additional upstream open status codes.

    Yogiyo's live shopyo list/detail APIs currently return snake_case fields such as `location`, `review`, `vendor_categories`, `open_status`, and `serving_type`. The provider now preserves those evidence-backed fields in the normalized restaurant contracts instead of dropping them when the upstream branch does not use the older camelCase fixture shape. The provider also stops sending an empty `category_code` for all-store shopyo discovery because the live endpoint rejects that request shape, and it accepts additional upstream open-status values observed in adjacent live audits while continuing to expose `is_open: true` only for `OPENING_TIME`.

    Affected surface
    yogiyo/find-restaurants, yogiyo/restaurant-full
    Action required
    No
    Migration guidance
    Existing valid callers can continue using the same inputs. Clients that exhaustively switch on `open_status_code` should handle the additional closed-like values `HOLIDAY`, `TEMP_HOLIDAY`, and `PAUSE`; only `OPENING_TIME` is normalized as `is_open: true`.
  64. AddedShipped

    CatchTable now exposes waiting order menus and accepts explicit frontend-shaped waiting order payloads for order-required waiting registration.

    This additive update mirrors the current CatchTable frontend waiting flow: fetch waiting menus, precheck the selected order, then create the waiting entry with explicit `orderLineItems`. The provider-owned health journey can now probe order-required waiting shops using a minimum canary order derived from non-out-of-stock menu evidence.

    Affected surface
    catchtable/waiting-menus, catchtable/register-waiting
    Action required
    No
    Migration guidance
    Existing register-waiting calls for non-order-required shops continue to work. For shops where waiting-info reports `order_required: true`, call `waiting-menus` first, let the user select menu items, then pass `order.order_line_items` into `register-waiting`; calls without order lines still fail closed before side effects.
  65. BreakingShipped

    CatchTable waiting-info now exposes upstream waiting registration preconditions so clients and health checks can avoid unsupported order-required waiting registrations.

    This additive contract update fixes a value-retention gap in CatchTable waiting preflight data. Upstream waiting-shop responses already expose order, table, and person-option preconditions. The provider now returns normalized fields for those signals and the waiting health journey skips order-required candidates until order payload support is implemented.

    Affected surface
    catchtable/waiting-info, catchtable/register-waiting
    Action required
    No
    Migration guidance
    Existing clients can continue reading the previous waiting-info fields. Clients that automate waiting registration should inspect `order_required`, `required_order_menu`, `tables`, `person_options`, and person-count constraints before calling `register-waiting`; `register-waiting` now fails closed with `WAITING_ORDER_REQUIRED` instead of attempting an empty-order upstream write for order-required shops.
  66. EmergencyShipped

    Modu Parking start-payment now matches the current webapp payment payload for shared NaverPay/NicePay and standard ticket payment URL creation.

    `modu-parking/start-payment` now mirrors the current Modu Parking frontend payment request shape more closely: - shared-parking `using_time` is normalized to the numeric `usingTime` value returned by the current `/ticket/share/{shareSeq}/time` response and submitted by the webapp; - `check-availability` now exposes `slots[].using_time_minutes` so callers no longer need to parse a display label before calling `start-payment`; - guest login uses the webapp `guestSeq` source (`guest_seq`, default `0`) rather than requiring `guestSeq` from SMS verification; - standard ticket payment URL creation no longer sends an extra `phone` field in the final `/ticket/payment/webview/{pgType}` payload. The existing SMS verification request remains unchanged, and shared-parking callers that send integer fields as decimal digit strings continue to parse successfully.

    Affected surface
    modu-parking/start-payment, modu-parking/check-availability
    Action required
    Yes
    Migration guidance
    Send shared-parking using_time from check-availability slots[].using_time_minutes. Decimal digit strings are still accepted for compatibility, but booleans, arrays, exponent strings, and empty values are rejected. If you have a Modu webapp guestSeq from URL/storage, pass it as guest_seq; otherwise the operation uses the current webapp default of 0.
  67. EmergencyShipped

    Modu Parking start-payment can now create NaverPay and NicePay payment URLs from one verified SMS session.

    `modu-parking/start-payment` now supports generating multiple supported payment gateway URLs from the same verified SMS session. Use `pg_types` when you need both NaverPay and NicePay URLs from one checkout attempt. The response keeps `payment_url` and `pg_type` for the first requested gateway and also returns `payment_urls` with each generated gateway URL. Existing callers that request a single gateway with `pg_type`, or omit `pg_type` to use the default NicePay path, do not need to change.

    Affected surface
    modu-parking/start-payment
    Action required
    Yes
    Migration guidance
    To create both payment URLs after one SMS verification, call start-payment once with pg_types set to ["naverpay","nicepay"]. Existing single-gateway calls with pg_type, or with pg_type omitted for the default NicePay URL, continue to work.
  68. EmergencyShipped

    Modu Parking start-payment now rechecks live purchasability, slot availability, and price/window parity before creating a payment URL.

    `modu-parking/start-payment` now fail-closes on the same live availability conditions that the Modu Parking frontend uses before payment: - ticket payments re-fetch the current ticket detail and daily purchase window, then reject non-purchasable/sold-out tickets, stale prices, and unavailable prediction windows before SMS verification; - shared-parking payments re-fetch the current shared time slots, then reject unavailable `using_time` selections and stale prices before SMS verification; - `check-availability` exposes shared-parking duration/price candidates, not a guaranteed reservation; Modu can still reject the final shared payment URL request if the space becomes full or is already in use; - upstream SMS verification, guest login, SMS send, and payment WebView calls now preserve the failing upstream branch and a redacted response-body excerpt for diagnostics instead of reporting only a generic HTTP status; - final shared payment URL rejections with Modu vendor code `10841` are surfaced as `NOT_PURCHASABLE` so API callers can show a business failure instead of treating it as a transient provider error. Business flow for API callers: 1. Use `search-parking` to choose a row. `parking_kind="ticket"` follows `parking-detail`; `parking_kind="shared"` follows `check-availability`. 2. For ticket payments, copy the selected `parking-detail.available_days[]` prediction window and current price into `start-payment`. 3. For shared payments, copy `check-availability.slots[].using_time_minutes` and `slots[].price` into `start-payment`. These values select a current duration/price candidate only; they do not hold inventory. 4. If `start-payment` returns `NOT_PURCHASABLE`, treat it as a user-facing business outcome such as full, already in use, stale price, or stale time selection. Ask the user to choose another parking option instead of retrying the same payload blindly.

    Affected surface
    modu-parking/start-payment, modu-parking/check-availability
    Action required
    Yes
    Migration guidance
    For ticket payments, pass price or total_price, point, predict_begin_time, and predict_end_time copied from parking-detail.available_days and price_info. For shared parking, pass using_time and price from check-availability, but treat those values as current duration/price candidates rather than a reservation. start-payment now fails before SMS verification when the selected ticket or shared slot is stale, and returns NOT_PURCHASABLE with upstream diagnostics if Modu rejects final shared payment URL creation because the space is full or already in use.
  69. BreakingShipped

    Modu Parking start-payment now creates one selected payment URL per SMS verification, adds the current Mobilians gateway, and requires the shared-parking slot amount.

    `modu-parking/start-payment` now mirrors the current Modu Parking webapp payment flow: the webapp chooses one payment gateway and calls one `/ticket/payment/.../webview/{pgType}` endpoint per verified SMS session. The previous `pg_types` array path has been removed from the public input contract because it generated multiple upstream payment URL requests from a single ceremony and made health-check failures ambiguous. Supported `pg_type` values are now `nicepay`, `naverpay`, and `mobilians`, matching the current webapp gateway list. The default gateway is `nicepay`, matching the webapp's default selected option. Shared-parking payment URL creation now requires the amount evidence (`price` or `total_price`) copied from `check-availability`, so callers do not accidentally submit a zero-price payload that the upstream rejects. Standard ticket payments also accept the current webapp's amount and exit-window fields (`price`, `total_price`, `predict_exit_begin_time`, `predict_exit_end_time`) when available.

    Affected surface
    modu-parking/start-payment
    Action required
    Yes
    Migration guidance
    Stop sending pg_types. Send a single pg_type value (nicepay, naverpay, or mobilians) when a specific gateway is needed; when omitted, start-payment follows the current Modu webapp default of nicepay. Shared-parking callers must pass price or total_price from check-availability. Use separate start-payment/SMS attempts when you need to validate multiple payment gateways.
  70. BreakingShipped

    Modu Parking and Yogiyo now reject malformed agent-invented payment/order fields before upstream calls.

    APIFuse tightened two agent-facing provider contracts after reviewing malformed tool-call patterns from an adjacent connector project. The change makes invalid inputs fail at schema validation instead of silently stripping fields or defaulting risky payment values. Modu Parking search results now include `parking_kind` and `next_tool` so agents can route shared parking directly to `check-availability`. `start-payment` no longer defaults shared `using_time`; callers must choose a current slot from `check-availability`, pass exactly one target, and include the vehicle number. Yogiyo order item schemas are now strict and bounded. Valid callers that already pass ids from `restaurant-full` continue to work; callers that were sending generated menu names, prices, or arbitrary option payloads must remove those fields.

    Affected surface
    modu-parking/search-parking, modu-parking/start-payment, yogiyo/order-preview, yogiyo/place-order
    Action required
    Yes
    Migration guidance
    Modu Parking clients should follow search-parking item routing: parking_kind=\"ticket\" uses parking-detail(ticket_id), while parking_kind=\"shared\" skips parking-detail and calls check-availability(share_seq). start-payment now requires car_number, and shared payments must pass using_time copied from check-availability; arbitrary payment fields are rejected. Yogiyo order-preview and place-order items must contain only restaurant-full ids: item_id, category_id, quantity 1-99, and options with section_id/option_id; do not include names, prices, display labels, or other invented fields.
  71. BreakingShipped

    KakaoMap, Modu Parking, and Yogiyo provider responses no longer publish fabricated empty or defaulted fields when upstream data is absent.

    APIFuse hardened provider normalization to stop hiding upstream contract gaps behind guessed fallbacks. The affected operations now preserve evidence-backed fields only when the observed upstream branch provides them. This prevents clients from mistaking missing review, fee, URL, or availability data for a real zero/empty value. Customers should distinguish absent optional fields from explicit `0`, `false`, or concrete status values.

    Affected surface
    kakaomap/search, modu-parking/search-parking, modu-parking/parking-detail, modu-parking/check-availability, modu-parking/start-payment, yogiyo/find-restaurants, yogiyo/restaurant-full, yogiyo/order-preview, yogiyo/place-order
    Action required
    Yes
    Migration guidance
    KakaoMap search callers must treat place_url as optional and use confirm_id/name/address for selection when upstream omits a place URL. Modu Parking search callers should choose follow-up calls from ticket_id/share_seq evidence; generated search metadata no longer carries synthetic parking_kind/next_tool hints. Modu Parking parking-detail callers must provide ticket_id, check-availability callers must provide share_seq, and start-payment callers must provide using_time, point, and price or total_price explicitly for shared parking flows. Yogiyo find-restaurants and restaurant-full callers must treat rating, review_count, delivery_fee, delivery time range, free delivery threshold, open_status_code, menu names, menu prices, menu descriptions, option names, option prices, and below_minimum_order_allowed as optional unless the upstream branch actually returned those signals. Yogiyo order-preview callers must provide shop_id and at least one item explicitly; Yogiyo place-order callers must treat order_number and store_name as optional when Yogiyo's order submit response omits them. Do not rely on APIFuse defaulting absent counts, fees, names, or prices to 0 or an empty/placeholder string.
  72. BreakingShipped

    Naver Flight and KakaoMap search can return larger result windows while preserving upstream response quality.

    Naver Flight search now exposes the full upstream result window through `maxResults` while keeping the provider's upstream `flightFilter.limit` at 200. This avoids reducing fare quality for slow-arriving Naver Flight SSE snapshots. KakaoMap public place search now accepts `page_size` up to 200 after live verification that the upstream `search/place.json` endpoint returns 200 place rows for larger pages. Existing calls without `page_size` keep the previous page size of 10.

    Affected surface
    naver-flight/search-flights, naver-flight/search-oneway-flights, kakaomap/search
    Action required
    No
    Migration guidance
    Existing callers can continue using the previous defaults. Naver Flight callers that need the full Naver fare window may request maxResults up to 200; the upstream Naver Flight search payload continues to request limit=200. KakaoMap search callers may pass page_size up to 200; omitting page_size preserves the previous default page size of 10.
  73. BreakingRemoved

    Naver Map now exposes only connection-free public APIs; saved-place login APIs are disabled.

    Naver can present account-protection CAPTCHA before the expected 2FA/app approval step during login. APIFuse does not automate CAPTCHA solving or ask users to paste browser cookies, so the session-required saved-place operations are removed from the active provider catalog for now. The remaining Naver Map operations are public/read-only and require no APIFuse Connection.

    Affected surface
    naver-map/collections, naver-map/collection-places, naver-map/place-detail-auth, naver-map/export, naver-map/search, naver-map/geocode, naver-map/place, naver-map/place-reviews, naver-map/transit-info, naver-map/car-directions, naver-map/transit-directions, naver-map/walk-directions, naver-map/bicycle-directions
    Action required
    Yes
    Migration guidance
    Stop calling `naver-map/collections`, `naver-map/collection-places`, `naver-map/place-detail-auth`, and `naver-map/export`. Use the remaining public Naver Map search, geocode, place, reviews, transit, and directions operations without a Connection. Saved-place export will return only after a safe non-cookie-paste login path can handle upstream Naver challenges without CAPTCHA bypass.
  74. BreakingShipped

    Provider read operations now retain upstream availability, queueing, delivery-fee, and payment handoff signals that were previously dropped by normalization.

    This is an additive provider contract update from the provider value-retention audit. It preserves upstream-provided actionability signals that customers need for safe read-before-write automation without exposing raw upstream payloads wholesale. The CatchTable change prevents waiting discovery from probing shops that upstream search already marks as not remotely waitable. Modu Parking now returns coupon prediction times needed by `start-payment`. Yogiyo now exposes mobile-web-confirmed open-status and delivery-fee signals used by the official frontend for restaurant availability and cart calculations.

    Affected surface
    catchtable/search, catchtable/waiting-info, modu-parking/parking-detail, yogiyo/find-restaurants, yogiyo/restaurant-full
    Action required
    No
    Migration guidance
    Existing clients can continue reading the previous fields. Clients that need safer automation should prefer the new optional fields: CatchTable search `waitingAvailable` and `waitingCount`; CatchTable waiting-info `remote_waiting_available`, `waiting_disabled_reason`, and `possible_remote_waiting_min_count`; Modu Parking parking-detail `available_days[].predict_begin_time` and `predict_end_time`; Yogiyo restaurant rows `open_status_code`, delivery time range fields, `delivery_fee_tiers`, `free_delivery_threshold`, and `below_minimum_order_allowed`.
  75. BreakingShipped

    Yogiyo now uses a connection-free anonymous order session instead of Personal MCP app-account Connections.

    Yogiyo's upstream user journey is an anonymous guest checkout with phone/SMS verification, not a reusable personal app-account login. The provider now matches the same frontend UX pattern as Modu Parking: discovery and cart preview run without a Connection, `verify-phone` creates a short-lived server-side anonymous session, and the following OTP/order handoff steps consume the returned `yogiyo_session_id`. Raw Yogiyo guest JWT/customer material is no longer represented as an APIFuse Connection or model-visible credential. Generated developer and MCP metadata now marks all Yogiyo operations as `authMode: none` and `requiresConnection: false`, so Personal MCP account settings no longer offer Yogiyo as an app account to connect.

    Affected surface
    yogiyo/find-restaurants, yogiyo/restaurant-full, yogiyo/order-preview, yogiyo/verify-phone, yogiyo/confirm-phone, yogiyo/place-order
    Action required
    Yes
    Migration guidance
    Stop creating or passing Yogiyo APIFuse Connections. Call `yogiyo/verify-phone` without `X-ApiFuse-Connection-Id`, persist the returned opaque `yogiyo_session_id` only for the current checkout attempt, then pass that id to `yogiyo/confirm-phone` and `yogiyo/place-order`. If the session expires, restart at `verify-phone`. Read operations remain connection-free.
  76. BreakingShipped

    CatchTable reservation table type inputs now use explicit table type codes and clearer reserve errors.

    CatchTable reservation table selection is now validated at the operation boundary. The `table_type` field for `catchtable/availability` and `catchtable/reserve` accepts only the documented finite table type codes, so invalid free-form table type values fail fast as request validation errors. For shops/times that require a concrete table choice, `catchtable/reserve` now returns `TABLE_SELECTION_REQUIRED` with customer-actionable guidance instead of surfacing an ambiguous upstream failure. Reservation write canaries also check availability with concrete table type codes before attempting a synthetic reservation.

    Affected surface
    catchtable/availability, catchtable/reserve
    Action required
    Yes
    Migration guidance
    Use one of the documented CatchTable table type codes (`_ALL_`, `H`, `R`, `T`, `B`, `W`, `D`, `N`) for `catchtable/availability` and `catchtable/reserve`. If `catchtable/reserve` returns `TABLE_SELECTION_REQUIRED`, retry with one of the concrete table type codes listed in the error message; do not retry by guessing from failed reserve attempts.
  77. PatchRemoved

    The legacy `ohouse/today_deals` alias now has a unique MCP tool-router name so it no longer collides with the canonical `ohouse/today-deals` operation.

    The operation API path and response contract are unchanged. This only disambiguates the generated MCP/developer metadata for the legacy alias.

    Affected surface
    ohouse/today_deals
    Action required
    No
    Migration guidance
    No client migration is required. API callers continue to use `/v1/ohouse/today_deals`; MCP clients should discover the regenerated tool metadata instead of hard-coding sanitized names.
  78. BreakingRemoved

    Ohouse expands from Today Deals-only extraction into a Daiso-style public read provider covering commerce, content, metadata, reviews, Q&A, promotions, and comments.

    The Ohouse provider now uses HAR and live browser-TLS evidence to expose stable public `/api` and `/apig` surfaces instead of relying only on recursive SSR payload extraction. New read-only operations cover product search/category/detail, product options, delivery, reviews, questions, recommendations, deal products, coupon display metadata, exhibitions, navigation metadata, search trends, promotion cards, content cards, product-used cards, project detail/recommendations, card collection recommendations, and public comments. Volatile Next.js build-data URLs and analytics or user mutation endpoints are cataloged in source but are not exposed as customer operations.

    Affected surface
    ohouse/today-deals, ohouse/today_deals, ohouse/search_products, ohouse/browse_store_category, ohouse/browse_product_categories, ohouse/get_product_detail, ohouse/get_products_by_ids, ohouse/get_product_options, ohouse/get_product_delivery, ohouse/get_product_reviews, ohouse/get_product_questions, ohouse/get_product_recommendations, ohouse/get_deal_products, ohouse/get_product_coupons, ohouse/get_exhibition_section_items, ohouse/get_site_metadata, ohouse/get_search_trends, ohouse/get_promotions, ohouse/search_cards, ohouse/get_product_used_cards, ohouse/get_project_detail, ohouse/get_project_recommendations, ohouse/get_card_collection_recommendations, ohouse/get_comments
    Action required
    Yes
    Migration guidance
    Existing `ohouse/today-deals` callers should regression-test strict response-schema assumptions because the operation now prefers the stable feed API, returns stronger product identifiers when upstream exposes them, and adds source API metadata. Callers that only read prior deal fields such as title, brand, URL, price, discounts, reviews, free_delivery, sold_out, and source_url remain supported. New operations are additive.
  79. PatchShipped

    TypeScript providers now use browser-grade `impit` TLS/HTTP2 impersonation behind the existing `ctx.tls.fetch` API; Ohouse no longer needs a Python `curl_cffi` runtime dependency.

    This keeps provider operation code simple: authors use the existing `ctx.tls.fetch` API and SDK stealth profiles while the SDK owns browser-grade TLS/HTTP2 impersonation internally.

    Affected surface
    provider-sdk, ohouse
    Action required
    No
    Migration guidance
    Existing TypeScript provider code continues using `ctx.tls.fetch`. No backend selector or Python runtime setup is required.
  80. BreakingShipped

    Provider temporal and closed-option inputs now reject ambiguous free-form strings at schema validation time instead of letting malformed values reach upstream APIs.

    This narrows public provider input schemas for date, time, datetime, and finite routing-option fields so agent/tool layers fail fast before dispatching ambiguous temporal values or unsupported options to upstream services. Existing clients that already send the documented formats continue to work; clients relying on loose strings should normalize before calling the operation.

    Affected surface
    catchtable/availability, catchtable/reserve, kakaomap/car-directions, kakaomap/transit-directions, korea-weather/mid-forecast, korea-weather/short-forecast, korea-weather/weather-by-address, modu-parking/start-payment, naver-flight/search-flights, naver-flight/search-oneway-flights, naver-map/transit-directions
    Action required
    Yes
    Migration guidance
    Update callers to send exact documented wire formats. CatchTable reservation dates and returned availability date_slots use YYYY-MM-DD, and reservation times use HH:MM such as 19:00, not 1900 or 7pm. KakaoMap transit times and KMA base times must use compact HHmm. Naver Map and Modu Parking prediction datetimes must include an ISO 8601 timezone. Naver Flight dates must use YYYY-MM-DD. KakaoMap car priority and transit sort must use the documented enum values.
  81. BreakingShipped

    Daiso now uses the renewed mall fapi contract and adds grouped product, review, store, inventory, catalog, recommendation, metadata, and promotion operations.

    The Daiso provider has moved from the retired mall website API path to the renewed `fapi.daisomall.co.kr` and current mall read endpoints captured from the renewal HAR. The existing `daiso/products` operation remains available but now resolves product discovery through the renewed FindStoreGoods flow, so customers should regression-test any strict response-shape assumptions. New grouped operations expose detail, reviews, store lookup, pickup inventory, product availability, catalog, trend, recommendation, metadata, and promotion surfaces while preserving sanitized source-payload coverage and partial-failure metadata.

    Affected surface
    daiso/search-products, daiso/product-detail, daiso/product-reviews, daiso/search-stores, daiso/inventory
    Action required
    Yes
    Migration guidance
    Existing daiso/products callers should verify response mappings against the renewed FindStoreGoods-backed schema and prefer the new grouped operations when they need details, reviews, stores, inventory, or catalog fanout.
  82. BreakingShipped

    KakaoMap transit info now publishes explicit branch schemas.

    APIFuse now removes the remaining unknown response-schema fields from provider API docs without inventing upstream contracts. `kakaomap/transit-info` exposes explicit bus stop, bus line, and subway station response branches.

    Affected surface
    kakaomap/transit-info
    Action required
    Yes
    Migration guidance
    KakaoMap transit-info callers should read the documented bus-stop, bus-line, or subway-station branch fields under info instead of relying on arbitrary upstream raw fields.
  83. BreakingShipped

    Provider schemas now reject unsupported closed-domain strings instead of accepting broad string values.

    APIFuse now models known finite provider contract values as enums or standard-code patterns rather than accepting arbitrary strings. This makes OpenAPI output and SDK-generated clients fail fast for unsupported values such as unknown payment gateways, typoed sort options, or invalid result/status codes. The affected operations keep their existing runtime behavior for valid callers. Clients that were sending out-of-contract values should migrate to the documented enums shown in the operation schema. Fields that are intentionally upstream-extensible, such as map category taxonomies or CMS section types, remain open strings and are documented as open-world values instead of being narrowed prematurely.

    Affected surface
    catchtable/reserve, catchtable/cancel-reservation, catchtable/register-waiting, catchtable/cancel-waiting, korea-parcel-tracking/carriers, yogiyo/find-restaurants, yogiyo/place-order
    Action required
    Yes
    Migration guidance
    Update callers to send only documented enum values for closed domains. Yogiyo search sort must be one of recommended, rating, distance, delivery_fee, or delivery_time; Yogiyo place-order reports NAVER_PAY as the payment gateway; Catchtable action-result statuses are the documented successful terminal status for that action; Delivery carrier country codes are lowercase ISO 3166-1 alpha-2 values.
  84. BreakingShipped

    Modu Parking start-payment now exposes the shared-parking payment fields and can create NaverPay and NicePay URLs from one verified SMS session.

    `modu-parking/start-payment` now aligns its shared-parking payment WebView request with the current Modu Parking webapp contract. The operation accepts optional shared-payment amount fields (`price`, `point`, `total_price`) plus `car_number` and maps them to the upstream `carNum`, `price`, `point`, `totalPrice`, `platform`, and `authCodeSeq` payload. This is primarily an enablement change for real-SMS health journeys and shared-parking payment URL creation. Existing clients are not forced to migrate immediately, but shared-parking payment flows should pass the price returned by `check-availability` and a valid vehicle number for reliable payment URL generation. When `pg_types` is `["naverpay","nicepay"]`, `start-payment` verifies the SMS code once, obtains the upstream guest session once, then creates both NaverPay and NicePay WebView URLs. The primary `payment_url` follows `pg_type`, and `payment_urls.naverpay` / `payment_urls.nicepay` exposes the PG-specific URLs.

    Affected surface
    modu-parking/start-payment
    Action required
    No
    Migration guidance
    Existing ticket_id and share_seq callers can continue using the operation. Shared-parking callers may now pass price, point, total_price, and car_number from check-availability/user input so the provider can create the payment WebView URL against the current Modu Parking contract. Set pg_types to ["naverpay","nicepay"] when both NaverPay and NicePay URLs are needed after a single SMS verification; keep pg_type as the primary gateway.
  85. BreakingShipped

    Adds Korean commerce public read providers and restores Daiso pickup inventory with a normalized stock contract.

    APIFuse now exposes additional public, read-only Korean commerce providers for Market Kurly product lookup, Daangn public listings, Danawa product and price comparison, and Ohouse Today Deals discovery. Daiso inventory is no longer modeled as an unsupported legacy lookup: it performs the current non-login pickup-stock ceremony and returns explicit store stock state instead of relying on request success as availability. The only compatibility-impacting existing public operation is `daiso/inventory`. Clients that consumed the previous unsupported shape should read `retrieval_status` and per-store stock fields from the new normalized response. All other operations listed here are newly added public provider operations.

    Affected surface
    daiso/inventory, market-kurly/search-products, market-kurly/count-products, market-kurly/product-detail, daangn-marketplace/used-goods-search, daangn-marketplace/used-goods-detail, daangn-marketplace/realty-search-listings, daangn-marketplace/realty-listing-detail, daangn-marketplace/jobs-search, daangn-marketplace/jobs-detail, daangn-marketplace/cars-search, daangn-marketplace/cars-detail, danawa/search-products, danawa/get-offers, danawa/compare-products, ohouse/today-deals
    Action required
    Yes
    Migration guidance
    Daiso inventory callers should migrate from the previous unsupported inventory response contract to the new pickup-stock response fields: selected_store, retrieval_status, stores[].in_stock, stores[].quantity, and stores[].inventory_label. New Market Kurly, Daangn, Danawa, and Ohouse operations are additive public read tools and require no migration.
  86. BreakingShipped

    CatchTable public restaurant read operations no longer require a user-owned connection reference.

    CatchTable search, restaurant detail, reviews, and reservation availability lookup are now modeled as public read tools in the APIFuse MCP and OpenAPI contracts. Agents can discover and call these operations without asking users for a connected CatchTable account. Customer-owned account references remain required for waiting operations and for actions that inspect or mutate a user's own reservations, waitings, or bookings.

    Affected surface
    catchtable/search, catchtable/shop, catchtable/reviews, catchtable/availability
    Action required
    No
    Migration guidance
    Remove externalRef from these restaurant read-only calls if your client was sending one only to satisfy the old schema. Booking, cancellation, waiting operations, and user status calls still require a connection reference.
  87. AddedPre-GA

    APIFuse now publishes a public changelog and operation contract baseline before launch.

    APIFuse now tracks provider operation contract versions, compatibility hashes, and customer-visible changelog entries before general availability. Existing provider operations start at contract version `1.0.0`; no customer migration is required for this pre-GA baseline.

    Affected surface
    platform-docs, provider-operations
    Action required
    No
    Migration guidance
    none