고객이 알아야 할 APIFuse 변경 사항

japan-post-zip 프로바이더가 새로 추가되었습니다.

jma-weather 프로바이더가 새로 추가되었습니다.

korea-disaster-alert 프로바이더가 새로 추가되었습니다.

korea-emergency-hospital 프로바이더가 새로 추가되었습니다.

korea-ev-charger 프로바이더가 새로 추가되었습니다.

korea-fuel-price 프로바이더가 새로 추가되었습니다.

korea-holiday 프로바이더가 새로 추가되었습니다.

korea-pharmacy 프로바이더가 새로 추가되었습니다.

korea-train-schedule 프로바이더가 새로 추가되었습니다.

swing-taxi 프로바이더가 새로 추가되었습니다.

weverse/get-app-state 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/get-artist-highlight 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/get-comment 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/get-community 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/get-community-tab 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/get-live-tab 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/get-member 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/get-post 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/get-posts 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-category-media 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-comment-artist-replies 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-comment-replies 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-community-all-media 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-community-media-categories 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-fan-letter-posts 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-feed-posts 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-group-communities 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-groups 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-live-posts 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-media-group-posts 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-member-comments 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-member-posts 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-post-artist-comments 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/list-post-comments 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/resolve-community 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/search-communities 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-artist-banners 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-artist-recent-sales 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-home-banners 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-home-notices 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-marketing-banners 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-pickup-banner 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-pickup-detail 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-pod-sales 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-recent-sales 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-recommend-sales 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-recommended-sales 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-return-exchange-info 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

weverse/shop-sale-curation 오퍼레이션의 공개 API 계약이 변경되었습니다.

## 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 operations now declare `connectionMode: "none"` and can be called without `X-ApiFuse-Connection-Id`. Requests that keep sending `X-ApiFuse-Connection-Id` continue to work unchanged. 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`.

hotpepper-gourmet 프로바이더가 새로 추가되었습니다.

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.

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.

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`.

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.

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.

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.

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

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.

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.

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`.

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.

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.

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.

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.

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`.

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

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.

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.

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.

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.

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.

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`.

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.

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.

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.

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.

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.

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.

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`.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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`.

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`.

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.

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.

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.

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`.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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`.

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.

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.

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.

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`.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.