Changelog
The korea-weather-forecast/forecast-version operation is no longer available as of October 23, 2026. It read KMA's forecast version endpoint (예보버전조회, getFcstVersion) on data.go.kr. Since at least October 14, 2026, that endpoint has answered every valid request without a real version: short-term forecast files return a 1970 placeholder stamp, and observation and ultra-short forecast files return an application error. On October 23, 2026, the same endpoint on KMA's API Hub (apihub.kma.go.kr) gave the same answers. KMA has not announced an end of service, but no request returns a version, so the operation could only answer that there was no data.
Stop calling korea-weather-forecast/forecast-version and remove it from saved tool lists and workflows. There is no replacement operation. If you used it to check freshness before reading a forecast, call short-forecast, ultra-short-forecast, or ultra-short-observation without base_date and base_time: they read the latest batch KMA has published. The operation used APIFuse-managed access and no customer connection, so there is nothing to clean up.
availability now accepts person from 1 to 80, the range CatchTable's own app offers when choosing a party size. It used to stop at 20, so a larger party could not be checked at all.
BREAKING for callers that read action_hint or next_action. The bound transition runs from the 2026-07-20 contract to the 2026-10-21 release. (1) Request: person accepts 1 to 80 (was 1 to 20), the range CatchTable's own party picker offers; a value above 80 fails input validation (HTTP 400). Other fields are unchanged. (2) Response, removed: action_hint and next_action (removed 2026-07-21); decide the next call from date_slots, time_slots and the fields below. (3) Response, added and optional: unavailable_reason is present only when CatchTable offers no time to this party on this date, with time_slots empty: person_out_of_range (the party is outside the sizes the shop takes online that day; min_person_count and max_person_count carry that range when CatchTable states it) or online_reservation_unavailable (the shop takes no online reservation that day). next_day_time_slots lists the times in time_slots that CatchTable shows as the next day; reserve one with the same date and time as listed. (4) Errors: the rate-limit code is RATE_LIMITED (429) instead of 429.
cancel-reservation now cancels only through a quote the user has seen. The caller reads reservation-detail with include_cancellation_quote=true, shows the refund, fee, additional charge and expiring points, and after explicit consent sends that quote's cancellation_token. The token is an opaque handle issued by reservation-detail and stays usable for 30 minutes; the quote is re-read just before dispatch, so changed terms return CANCELLATION_QUOTE_CHANGED instead of cancelling on terms the user did not accept.
BREAKING for every caller that still sends reservation_ref. The bound transition runs from the 2026-07-20 contract to the token-only release, so it also carries the reviewed-cancellation change of 2026-10-14. (1) Request: reservation_ref is no longer an accepted field and cancellation_token is required. Read reservation-detail with {reservation_ref, include_cancellation_quote: true}, show the user the refund, fee, additional charge and expiring points it returns, and after explicit consent call cancel-reservation with {cancellation_token} copied exactly as issued; reason, reason_code and reason_text stay optional. A token is usable for 30 minutes; the quote is re-read immediately before dispatch. A request without cancellation_token fails input validation (HTTP 400 invalid_request) and sends nothing to CatchTable. (2) Compatibility window: the 2026-10-14 release kept reservation_ref as a deprecated input (contract.deprecatedFields, removalAfter 2026-10-28) that cancelled only free cancellations and otherwise returned CANCELLATION_PREVIEW_REQUIRED; this release removes that input, its deprecatedFields declaration and the INVALID_INPUT and CANCELLATION_PREVIEW_REQUIRED codes of cancel-reservation (cancel-all-reservations still declares CANCELLATION_PREVIEW_REQUIRED). (3) Errors since 2026-07-20: CANCELLATION_QUOTE_UNAVAILABLE (409, terms cannot be verified, use CatchTable); CANCELLATION_QUOTE_CHANGED (409, obtain consent to a new quote); CANCELLATION_OUTCOME_UNKNOWN (409, verify reservation and payment history before another write); CANCELLATION_TOKEN_EXPIRED_UNSENT (400, details.dispatched false and restart_via reservation-detail: read a new quote and ask again); CANCELLATION_REFUSED (409, CatchTable refused with a reason code in details.upstream_result_code and details.dispatched refused; the reservation is still active and nothing was cancelled, so a newly consented quote may be sent later); reauth_required (reconnect the CatchTable session); the rate-limit code is RATE_LIMITED (429) instead of 429. AUTH_REQUIRED and UPSTREAM_ERROR are unchanged. (4) Response: unchanged (reservation_ref, status, optional cancelled_at).
discover previews dated reservation times for a party, and its person field now accepts 1 to 80, the range CatchTable's own app offers. It used to stop at 20.
The bound transition runs from the 2026-10-14 contract to the 2026-10-21 release. (1) Request: person accepts 1 to 80 (was 1 to 20), the range CatchTable's own party picker offers; it still defaults to 2, and a value above 80 fails input validation (HTTP 400). (2) Response, added and optional on each shops[] entry: unavailable_reason is present only when CatchTable offers no time to this party on the previewed date: person_out_of_range (the party is outside the sizes the shop takes online that day; min_person_count and max_person_count carry that range when CatchTable states it) or online_reservation_unavailable (the shop takes no online reservation that day). Nothing else changed and no field was removed.
When reservation-payment-ready has to ask for a choice before payment, its add-on options now carry the unit price and CatchTable's 19+ mark, the facts the CatchTable app shows next to each add-on. A party outside the sizes the shop takes online that day, or a day with no online reservation, is refused by name before anything is sent.
The bound transition runs from the 2026-10-14 contract to the 2026-10-21 release. (1) Request: unchanged. (2) Response, needs_input: add-on valid_options add unit_price_krw (KRW per unit, as CatchTable lists it) and age_verification_required (true when CatchTable marks the item 19+). Menu items that carry default_quantity or max_quantity may be answered together, one answer per item with its quantity. The no_payment_required and ready responses are unchanged. (3) Errors, new: PERSON_OUT_OF_RANGE (409, the party is outside the sizes the shop takes online that day; details.context carries min_person_count and max_person_count when CatchTable states them) and ONLINE_RESERVATION_UNAVAILABLE (409, the shop takes no online reservation that day). Both send nothing (details.dispatched false). No field or error code was removed.
reserve-answer now carries use_point, the points the user chose for the attempt; a point-only change sends use_point with an empty answers: [], since answers stays required. The attempt keeps the amount, and reserve-confirm resends it as payment.use_point only on the catch_pay branch, while the points branch confirms with {method: "points"} alone.
The bound transition runs from the 2026-10-14 contract to the 2026-10-21 release. (1) Request: optional use_point (KRW, 0 or at least 100) records the points the user stated for this attempt; reserve-confirm resends it as payment.use_point only on the catch_pay branch, while the points branch confirms with payment {method: \"points\"} alone and does not resend the stored amount. answers stays required and may be sent empty ([]) for a point-only change; otherwise send the new answers, as before. An answer's quantity applies to add-ons and to menu items whose option carries default_quantity or max_quantity; such menu items may be answered together, one answer per item with its quantity, and an absent quantity counts the item's default_quantity. (2) Response, needs_input: add-on valid_options add unit_price_krw (KRW per unit) and age_verification_required (CatchTable marks the item 19+). (3) Response, ready summary: payment_methods may list catch_pay, only when reserve declared it in accepted_payment_methods; points is no longer listed, because points are an amount the user chooses rather than a confirmation method, and points_applicable_krw is no longer returned. payment_amount_krw is the reservation form total before any deposit-free consent. The summary adds zero_deposit_available, meal_auto_pay_supported and time_is_next_day (a slot CatchTable lists under date but shows as the next day). For attempts declaring accepted_payment_methods it also adds shop_name, attempt_expires_at, points_balance_krw, catch_pay_card_ready, pay_now_amount_krw, pay_now_after_points_krw (when the chosen points apply), zero_deposit_pay_now_amount_krw, free_cancellation_until and, when the booking has a deposit, CatchTable's deposit_refund_policy and zero_deposit_cancellation_fee_policy tables with zero_deposit_fee_notice; catch_pay_status and penalty_option_available appear when catch_pay is listed. Show these terms to the user before reserve-confirm. (4) Errors: new ATTEMPT_EXPIRED_UNSENT (400, the attempt expired before anything was sent; start a new reserve), PERSON_OUT_OF_RANGE (409, the party is outside the sizes the shop takes online that day) and ONLINE_RESERVATION_UNAVAILABLE (409, no online reservation that day). No field or error code was removed.
reserve no longer creates a reservation. It starts an attempt that the server keeps: each response carries an opaque attempt_token, and either the choices still needed (needs_input) or a summary ready to confirm (ready). reserve-answer sends the user's new answers on that token, and reserve-confirm is the only call that books. Nothing is booked or charged by reserve.
BREAKING for every caller of reserve. The bound transition runs from the 2026-07-20 contract, when reserve created the reservation in one call, to the 2026-10-21 release. (1) Flow: reserve starts an attempt and books nothing. It returns {status: needs_input, attempt_token, required_selections, settled_selections?} or {status: ready, attempt_token, summary}. Relay required_selections to the user and send only the new answers with reserve-answer {attempt_token, answers}; settled decisions are kept server side and must not be re-sent. On ready, show the summary and create the booking with reserve-confirm {attempt_token, payment?}, which returns the created reservation (reservation_ref, status CONFIRMED or AWAITING_SHOP_CONFIRMATION). reserve itself no longer returns reservation_ref, status, shop_ref, visit_date or person_count at the top level. (2) Request: reservation_state and selected_options are removed; the start takes {shop_ref, date, time, person}. person accepts 1 to 80 (it had no upper bound), the range CatchTable's own party picker offers; a value above 80 fails input validation (HTTP 400). Optional accepted_payment_methods (none, points, catch_pay; at least one) declares the confirmation methods the caller can complete: catch_pay is offered only when declared, and the ready summary's payment and cancellation facts (shop_name, pay_now_amount_krw, deposit_refund_policy, zero_deposit_cancellation_fee_policy, free_cancellation_until, attempt_expires_at, catch_pay_status) appear only for attempts that declare it. Optional use_point (KRW, 0 or at least 100) records the points the user chose, and reserve-confirm must send the same amount. (3) Response details: required_selections[].valid_options carry availability, default_quantity, min_quantity and max_quantity, and for add-ons unit_price_krw and age_verification_required; menu items that carry default_quantity or max_quantity may be answered together, one answer per item with its quantity. summary.time_is_next_day marks a slot CatchTable lists under date but shows as the next day; it is booked with the same date and time. (4) Errors since 2026-07-20: TABLE_SELECTION_REQUIRED, INVALID_RESERVATION_STATE, INVALID_RESERVATION_SELECTION and STALE_RESERVATION_STATE no longer exist (those situations are needs_input rounds); the rate-limit code is RATE_LIMITED (429) instead of 429; new SLOT_UNAVAILABLE (409, ask for another time), PERSON_OUT_OF_RANGE (409, the party is outside the sizes the shop takes online that day; details.context carries min_person_count and max_person_count when CatchTable states them), ONLINE_RESERVATION_UNAVAILABLE (409, no online reservation that day), UPSTREAM_REJECTED (409, CatchTable's own rules refused it; follow the error fix), UPSTREAM_RESULT_CODE_UNREGISTERED (502, do not retry the same request) and reauth_required (reconnect the CatchTable session). AUTH_REQUIRED, RESERVATION_SELECTION_REQUIRED, PAYMENT_REQUIRED and UPSTREAM_ERROR are unchanged.
A CatchPay confirmation now carries pin, the payer's 4-digit CatchPay PIN as typed in a secure payment UI, in place of encrypted_catch_pay_password. The provider encrypts it with CatchTable's key for this confirmation only and never stores or returns it. A booking that charges nothing and has no meal auto-pay consent takes no PIN.
BREAKING for callers that pay with catch_pay. The bound transition runs from the 2026-10-14 contract to the 2026-10-21 release. (1) Request: in payment {method: catch_pay}, encrypted_catch_pay_password is removed and no longer required; send pin, the payer's 4-digit CatchPay PIN as typed in a secure payment UI, when the reservation charges the card (payment_amount_krw above 0 or auto_pay_consent). A booking with payment_amount_krw 0 and no auto_pay_consent takes no PIN, and a PIN sent for it is not used. The provider encrypts the PIN with CatchTable's key and never stores or returns it. card_id, use_point, penalty_consent and auto_pay_consent are unchanged; send the same use_point that reserve or reserve-answer recorded. The other payment branches and payment_method are unchanged. (2) Response: unchanged, except that needs_input add-on valid_options add unit_price_krw and age_verification_required. (3) Errors, all new: CATCHPAY_PASSWORD_MISMATCH (400) and CATCHPAY_PASSWORD_UNVERIFIED (502), nothing sent, retry the same attempt_token with a newly entered PIN only when the user asks; CATCHPAY_PIN_RESET_REQUIRED (409, the account holder must set a new CatchPay password in CatchTable first); SEAT_UNAVAILABLE (409, CatchPay create refused the seat, the attempt stays open: send the new choice with reserve-answer and confirm again); IDENTITY_VERIFICATION_REQUIRED (409, free attempts only, confirm again after the account completes identity verification in CatchTable); ADULT_MENU_NOT_ALLOWED (409, choose a menu without the adult-only item via reserve-answer); ATTEMPT_EXPIRED_UNSENT (400, nothing was sent; start a new reserve); PERSON_OUT_OF_RANGE (409) and ONLINE_RESERVATION_UNAVAILABLE (409). details.dispatched tells whether the call sent anything: false when nothing was sent, refused when CatchTable refused the create. No error code was removed.
daiso/stores contract version 2.0.0 adopts the canonical APIFuse free-text search field. The provider continues to send the query through Daiso's private store-search request parameter.
BREAKING. Update daiso/stores requests from keyword to query. The old keyword field is no longer accepted. Region filters, limits, response fields, and store-search behavior are unchanged.
The weverse/shop-logout operation is no longer available. Signing out of Weverse Shop invalidates the session used by the connection, so it is now handled when the connection is deleted.
Stop calling weverse/shop-logout and remove it from saved tool lists and workflows. To disconnect Weverse, delete the connection in the dashboard or call DELETE /connections/{connectionId}. APIFuse attempts to sign out of Weverse Shop before deleting the connection; if Weverse cannot complete sign-out, the connection is still deleted. If a workflow used shop-logout while keeping the connection, delete and reconnect instead because sign-out invalidates the saved session.
yogiyo/find-restaurants contract version 2.0.0 standardizes its public search and sort field names while preserving the exact private Yogiyo request parameters and sort-code mapping.
BREAKING. Update yogiyo/find-restaurants requests from keyword to query and from sort to sort_by. Existing sort values remain unchanged: recommended, rating, distance, delivery_fee, and delivery_time. The old field names are no longer accepted. Response fields and restaurant-search behavior are unchanged.
Provider operations now place each declaration axis in one namespace. Safety uses the required riskClass field, access uses connectionMode, and request examples use examples. Documentation locale keys, approval overrides, timeouts, error codes, and connection correlation parameters move to the operation root.
After the flat Provider SDK release is available, update the provider's SDK pin and migrate the whole repository in one change. Replace annotations.readOnly/destructive with an authored riskClass; do not copy the old implicit write fallback without reviewing the operation. Move toolRouter.connectionMode and connectionExternalRefParam to the operation root, and declare connectionMode on every operation of a credential-bearing provider. Move approval, timeoutMs, locale keys, normalization note keys, and errorCodes to the root. Replace inputExamples and docs.requestExample with examples entries that use scenarioKey and input. Remove annotations, toolRouter, docs, derivations, rateLimit, retryOnAuthRefresh, and toolRouter.name. Keep approval only when it intentionally differs from the riskClass-derived default. Do not partially migrate one provider repository.
Daangn Marketplace operations now classify error outcomes honestly instead of collapsing them into generic server errors:
Daangn Marketplace now classifies malformed, expired, cross-family, or otherwise invalid opaque ids as request validation failures. These failures return HTTP 400 with the existing INVALID_INPUT code and remain non-retryable until the caller supplies an id from the appropriate discovery operation.
daiso/product-reviews now exposes review attribute questions and their option distributions through stable APIFuse field names. Each non-null upstream option slot is emitted in slot order, and nullable fourth and fifth slots are omitted.
'Consume attributes as an array of { attribute_id, name, question?, total_count?, options: [{ label, count?, percent? }] } rows; previously the array contained the raw selRevwAttr data object with pdRevw and pdRevwAttr vendor fields. Consume keywords as a string array ordered by the upstream keywdSeq; previously each entry exposed a raw { pdNo, keywdMngNo, keywd, keywdSeq, frRgDtm } object. Summary fields and source_payloads are unchanged.'
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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
No action is required. This operation previously rejected requests without X-ApiFuse-Connection-Id; it now accepts connection-less calls and serves the same public Weverse content. Existing callers that keep sending a connection id continue to work unchanged. Weverse operations that read the signed-in user's own state or account (connection-health, get-account-info, get-current-user, get-dm-user, get-jelly-balance, get-membership-benefits, get-my-membership, get-unseen-notification-count, get-user-settings, list-dm-subscriptions, list-showcased-rooms, shop-cart-count, shop-logout) still 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.
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 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.
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.
For search and transit directions, replace public sort with sort_by. For search, sort_by: "distance" now requires both lat and lng, and the previously exposed radius input has been removed because KakaoMap ignored it. For route outputs, replace transit duration, walkTime, and transitTime with duration_sec, walk_sec, and transit_sec; replace car fare with toll_fee or taxi_fee. For transit-info, branch on top-level info_type and read normalized fields such as stop_id, lng, vehicle_locations, realtime_state_message, station_id, station_name, and subway_line_name instead of upstream-shaped names. Route callers may keep coordinate pairs or switch to origin and destination strings.
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.
Update KakaoMap callers to send open_now, include_reviews, include_photos, include_blog, and has_hipass as JSON booleans (true or false). String values such as "true" and "false" are no longer accepted.
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.
For car directions, send vehicle_type ("compact", "medium", "large") and has_hipass for fuel and toll computation; new optional waypoints (max 3), avoid, and priority inputs control routing. For transit directions, sort_by now accepts walk and transfer in addition to time (sorting is applied by the provider because KakaoMap ignores its sort parameter), max_results caps itineraries, and steps may include fast_exits, fast_transfers, and exit_direction. For place, use include_reviews, include_photos, and review_limit to control composite enrichment; confirm_id must be the numeric KakaoMap place id. For place-reviews, use page_size for pagination. For search, pass filter_tag tokens taken from the new available_filters field of a prior search response; free-text filter labels are not accepted. For geocode, optional lat and lng bias inputs must be provided together and the input must be an address, not a place name.
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.
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.
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 status is still a closed enum but now returns AWAITING_SHOP_CONFIRMATION in addition to CONFIRMED. Shops that review requests before accepting them create the reservation upstream in a confirmation-pending state; reserve previously failed those calls with UPSTREAM_ERROR even though the reservation already existed on CatchTable. Callers must handle the new value: treat it as \"request placed, awaiting the shop's confirmation\" and never present it to end users as a confirmed booking — CatchTable notifies the user once the shop confirms, and reservation-detail can be polled for the current state. reservation-detail status changes from a free-form string to the closed enum CONFIRMED | AWAITING_SHOP_CONFIRMATION | CANCELLED; it previously reported CONFIRMED for every non-cancelled reservation, including ones the shop had not confirmed. Callers that branched on other string values must switch to these three statuses.
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.
search output adds two fields: top-level next_offset (opaque cursor string, present only while more results remain — absent means the last page) and per-shop main_service (DINING for reservation-led shops, WAITING for waitlist-led shops; route WAITING shops through waiting-info before registering a waiting). The offset input is now the pagination cursor: send \"0\" (or omit it) for the first page and pass the previous response's next_offset unchanged for the next page. Numeric offset: 0 keeps working for the first page, but other computed numeric offsets were never functional — CatchTable rejects them with HTTP 500 — so callers that incremented offset must switch to next_offset. An unrecognized upstream main_service value fails the call with UPSTREAM_ERROR instead of being silently dropped.
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 output gains additive fields: optional strings biz_hours, holidays, parking, cancel_policy, reservation_note, lunch_price, dinner_price, optional facilities (string array), open_schedules (array of {schedule_type, open_time}), required menu ({menu_boards, categories[{name, description, items[{name, min_price, max_price, description, is_recommended, is_representative, image_url}]}], kids_menu_guide, allergy_guide}), and required subways (array of {station, lines, distance}). The previously accepted-but-ignored inputs include_reviews/review_limit are now honored: with include_reviews=true the output additionally carries reviews in the same {reviews[], total} shape as the reviews operation, limited to review_limit. Error behavior changed from partial tolerance to fail-closed: if required detail, menu, subway, or requested review data cannot be loaded, the operation now fails with UPSTREAM_ERROR instead of silently returning the legacy 9-field subset. Callers that only read the original 9 fields need no changes.
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.
This release closes two contract-fidelity gaps in the CatchTable waiting write path.
register-waiting gains two optional output fields: waiting_number (the 대기 번호 ticket number the shop displays to the customer) and shop_name; existing fields are unchanged, so readers only need updates if they validate the response with a closed schema. cancel-waiting reason is narrowed from a free-form optional string to the closed enum [\"CUSTOMER_CANCEL\"] with default CUSTOMER_CANCEL — the same code the CatchTable app frontend always sends. The old reason parameter was dead: the previous handler ignored it and posted the cancel with no body, so no caller behavior depended on its value. Callers that passed arbitrary reason text (for example \"changed my mind\") will now fail input validation; omit reason or send CUSTOMER_CANCEL. The cancel request now posts {\"cancelReasonCode\": \"CUSTOMER_CANCEL\"} to CatchTable, matching the first-party client instead of an empty body.
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.
restaurant-full menu list items no longer include image_url, and description is truncated to 100 characters with a trailing …. Existing option count summaries stay on every list item: has_options, option_section_count, required_option_section_count, optional_option_section_count, and option_item_count. menu_metrics keeps full aggregate counts. Callers that need the untruncated description or the menu image should call menu-item-options with the same shop_id and the selected item_id; its response now includes description and image_url when Yogiyo exposes them.
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 release fixes four production-impacting Modu Parking contract behaviors.
search-parking location labels are now geocoded through Modu Parking's own place search instead of a 3-entry lookup that silently searched 남산 for unknown labels: unresolvable labels fail with LOCATION_RESOLVE_FAILED, requests with neither coordinates nor a non-empty location are rejected at input validation (the location input no longer declares a default empty string — send lat/lng or a non-empty location), and searched_location now returns the resolved place name. parking-detail for monthly/period tickets (월주차권/정기권) now returns 200 with available_days: [], the new daily_schedule_supported: false field, and is_purchasable: false instead of failing; callers that treated any parking-detail failure as \"ticket not found\" must instead branch on the new TICKET_NOT_FOUND error code, which is now returned only for tickets that do not exist upstream. Monthly/period tickets cannot be purchased through start-payment: it rejects them with NOT_PURCHASABLE before verifying the SMS code or creating any payment request, so check is_purchasable before calling send-payment-sms (that separate operation sends a real SMS and takes no ticket reference) and hand users off via the parking-detail app_url. check-availability price_per_hour is now a derived hourly rate (round(price × 60 / using_time_minutes) of the first priced slot) instead of echoing the first slot's total price; a 30-minute 900 KRW slot now reports 1800, not 900.
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.
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.
Call daangn-marketplace/search-regions with a Korean administrative-region keyword, then pass one returned items[].id as region_id to used-goods-search, jobs-search, cars-search, realty-search-listings, or realty-search-complexes. The previous free-text region input has been removed from those operations.
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.
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.
Update clients that read korea-weather/short-forecast or korea-weather/weather-by-address.forecast. The short forecast payload now returns grid, current_observation, and hourly_forecasts. Replace top-level observed_at, temperature, humidity, wind_speed, precipitation_1h, precipitation_type, and sky reads with current_observation.*. Replace wind_speed with current_observation.wind.speed; read wind direction from current_observation.wind.direction. Replace forecasts with hourly_forecasts; forecast entries now include nested wind and humidity fields. Operation contract versions for short-forecast and weather-by-address are now 2.0.0.
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.
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.
Update provider IDs in operation paths. Use korea-national-law, korea-mfds-food-safety, korea-mfds-drug-safety, korea-mois-household-waste, korea-neis-school-meals, korea-parcel-tracking, korea-air-quality, korea-weather, naver-map, yogiyo, danawa, ohouse, and daiso. Operation IDs are unchanged unless already changed by earlier provider-specific contract hardcuts. Legacy provider IDs continue to route at the gateway as compatibility aliases, but new discovery, metadata, examples, and generated tools use canonical IDs only.
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.
Replace large_class_code, middle_class_code, small_class_code, and detail_class_code inputs on rakuten-travel/search-hotels-simple and rakuten-travel/search-vacant-hotels with area values returned by rakuten-travel/get-area-classes, such as japan/akita/tazawa or japan/tokyo/tokyo/F. Update get-area-classes callers to send optional query and limit inputs and read areas[] rows with area and label instead of area_classes or area_tree.
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.
Replace stationCode with station_id and stationName with station_name. Use interval values ten_minutes, one_hour, or one_day instead of HRFCO path codes 10M, 1H, or 1D. Read station.station_id, station.zero_elevation_meters, alert_levels.*_meters, station.forecast_station, water_level.station_id, water_level.interval, water_level.water_level_meters, and water_level.flow_cms instead of station_code, zero_elevation_m, alert_levels.*_m, is_forecast_station, water_level_m, and flow_rate_m3s.
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.
Existing valid KMA short-forecast inputs now use snake_case grid_x/grid_y plus optional base_date and base_time; weather-by-address keeps address and uses optional base_date/base_time; mid-forecast uses region_id plus optional ISO tm_fc. Stop sending legacy camelCase or upstream-style request keys such as gridX, gridY, baseDate, baseTime, regionId, tmFc, pageNo, numOfRows, or regId. Clients that validate or exhaustively switch on short-forecast precipitation_type or sky should use the documented normalized values: precipitation_type is none, rain, sleet, snow, or null; sky is clear, mostly_cloudy, overcast, or null. Mid-forecast clients should read relative forecast slots from day_offset and normalized temperature fields such as min_temperature/max_temperature rather than inferred calendar dates or legacy taMin/taMax-style fields. Treat UPSTREAM_SCHEMA_ERROR as an upstream contract drift signal rather than a no-data response.
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.
Replace numOfRows with limit in korea-mfds-food-safety/search requests. Read returned_count from summary.returned_count, and continue reading normalized product_name, company_name, violation_detail, and registered_date fields from items.
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.
For korea-neis-school-meals/school-search, replace educationOfficeCode with education_office_code, schoolName with school_name, pIndex with page, and pSize with limit. For korea-neis-school-meals/menu, replace educationOfficeCode with education_office_code, schoolCode with school_code, mealDate with meal_date, and mealKindCode values 1/2/3 with meal_type values breakfast/lunch/dinner. Read meals[].meal_type and meals[].meal_type_label instead of meal_type_code and meal_type_name, meals[].calories_kcal instead of calories, and meals[].dishes[] objects with name plus allergen_codes instead of raw dish strings.
This release standardizes the lh-notice public contract so callers interact with APIFuse-shaped field names rather than LH upstream request parameter names.
Replace list inputs panSs, uppAisTpCd, aisTpCd, cnpCdNm, panNm, panNtStDt, clsgDt, and pageSize with status, housing_type, subcategory_code, region, query, posted_date, closing_date, page, and limit. Pass housing_type as one of land, sale_housing, rental_housing, housing_welfare, or commercial instead of LH type codes 01, 05, 06, 13, or 22. Pass posted_date and closing_date as YYYY-MM-DD exact-date filters. Read applied filters from filters.housing_type, filters.subcategory_code, filters.posted_date, and filters.closing_date. Read notices from notice_id, detail_reference, posted_date, closing_date, and detail_url. Use each list item's detail_reference when calling detail. The detail operation now accepts only detail_reference and no longer accepts detailReference, panId, ccrCnntSysDsCd, or splInfTpCd directly. Detail output now returns notice.notice_id, notice.detail_reference, and supply_infos.
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.
For seoul-subway/arrival, replace stationName with station_name, startIndex with offset, endIndex with limit, and read query plus normalized arrival fields line_id, direction, destination, station_name, arrival_seconds, arrival_message, and previous_station_message. For seoul-bike/nearby, replace lat/lon/radius with latitude/longitude/radius_meters and read station_name, rack_count, available_bike_count, occupancy_percent, latitude, and longitude. For korea-air-quality/realtime, replace stationName with station_name, dataTerm DAILY/MONTH/3MONTH with data_term daily/monthly/three_months, and measuredAt with measured_at. For korea-mois-household-waste/info, replace districtName with district_name.
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.
Call catchtable/reservation-options for the exact shop_ref, date, visit_time, person, and table_type. Pass reservation_state to catchtable/reserve; when required_selections is present, pass one selected_options[] item with the matching selection_id and selection_value. Do not pass reservation_choice, reservation_choices, raw table/menu fields, add-on payloads, or provider request bodies.
This release completes a Daangn Marketplace contract standardization pass after the facade hardcut.
Replace only_on_sale with available_only on used-goods-search, realty-search-listings, and cars-search. Replace chart_trade_type with trade_type on realty-complex-price-history. Opaque ids, canonical URLs, normalized item envelopes, and read-only behavior are unchanged.
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.
If you reused the shared Daiso grouped-read output schema, remove handling for promotion-specific promotions and banners fields from browse-catalog, recommend-products, search-trends, and site-metadata consumers. Continue using each operation's catalog, recommendation, trend, or metadata fields for its primary result shape.
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.
Stop calling daiso/list-promotions. Use search-products, browse-catalog, search-trends, recommend-products, site-metadata, or store/search operations depending on the user intent. The shared Daiso grouped-read schema no longer includes the list-promotions operation branch or promotions/banners output fields.
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).
Replace itemName with query, pageNo with page, and numOfRows with limit. Read normalized medicine fields such as medicine_name, manufacturer_name, usage, drug_id, and summary instead of item_name, company_name, how_to_use, item_seq, page_no, and num_of_rows.
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.
Replace korea-national-law/search with search-legal-resources or a focused search-* operation, replace korea-national-law/detail with get or lookup-law-article, replace korea-national-law/terms with search-legal-terms plus get for term detail, and replace korea-national-law/compare with search-law-comparisons using snake_case request fields such as law_name and comparison_type. The old law, article, compare, and term request shapes are retired.
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.
For announcements, replace perPage with limit, biz_pbanc_nm with query, supt_regin with support_region, supt_biz_clsfc with support_field, pbanc_rcpt_bgng_dt with application_start_date in YYYY-MM-DD format, pbanc_rcpt_end_dt with application_end_date in YYYY-MM-DD format, aply_trgt with target_audience, biz_enyy with startup_age, biz_trgt_age with target_age, rcrt_prgs_yn Y/N with recruitment_status open/closed, and intg_pbanc_yn Y/N with integrated_announcement true/false. For business-info, replace perPage with limit, biz_yr with year, biz_category_cd with category_code, and supt_biz_titl_nm with query. Read results from items and summary instead of data and query.
This hard-breaking cleanup removes legacy low-level Daangn realty operations that were superseded by the facade contract introduced in daangn-marketplace-contract-hardcut.
Use realty-search-listings and realty-listing-detail for listings; realty-search-regions for region discovery; realty-search-complexes, realty-complex-detail, realty-complex-listings, and realty-complex-price-history for complex flows. Follow-up ids are now APIFuse opaque id values returned by search/list operations.
This release is a breaking hardcut of the Daangn Marketplace public provider contract.
Replace raw realty operation calls with facade operations. Use realty-search-listings and realty-listing-detail for listings; realty-search-regions for region discovery; realty-search-complexes, realty-complex-detail, realty-complex-listings, and realty-complex-price-history for complex flows. Follow-up ids are now APIFuse opaque id values returned by search/list operations. Use canonical_url instead of source_url, summary.returned_count instead of ad hoc count/source fields, and domain branches such as realty/job/car/used_goods instead of metadata. Jobs search no longer accepts only_on_sale.
This change tracks an additive enum value in Daangn's realty complex price-history GraphQL response.
This is a hard-breaking cleanup. Daiso no longer exposes duplicate compatibility operations or grouped endpoint summaries as the stable public API.
Replace removed operation ids with canonical kebab-case ids. Use search-products instead of products/search_products, product-detail instead of get_product_detail/product_detail, product-reviews instead of get_product_reviews/product_reviews, store-detail instead of get_store_detail/store_detail, check-pickup-availability instead of direct pickup inventory/location/product availability operations, search-trends instead of get_search_trends/search_trends, recommend-products instead of get_recommendations/recommend_products, and site-metadata instead of get_site_metadata/site_metadata. Replace page_size with limit and review sort with sort_by recommended/latest.
This hard-breaking cleanup removes legacy aliases and upstream-shaped Daiso operation ids so the public contract has one canonical name per Daiso capability.
Use search-products, product-detail, product-reviews, search-stores, store-detail, check-pickup-availability, browse-catalog, search-trends, recommend-products, site-metadata, and list-promotions. The stores and inventory operations remain available.
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.
Replace old snake_case Ohouse operation ids with the new kebab-case ids: search_products to search-products, browse_store_category to browse-products, browse_product_categories to product-categories, get_product_detail to product-detail, get_products_by_ids to products-by-id, get_deal_products to deal-products, get_exhibition_section_items to exhibition-products, get_product_options to product-options, get_product_delivery to product-shipping, get_product_coupons product branch to product-coupons, get_product_coupons deal branch to deal-coupons, get_product_recommendations to product-recommendations, get_product_reviews to product-reviews, get_product_questions to product-questions, get_product_used_cards to product-used-cards, search_cards to search-cards, get_comments to comments, get_project_detail to project-detail, get_project_recommendations to project-recommendations, get_card_collection_recommendations to card-collection-recommendations, get_promotions to promotions, get_search_trends to search-trends, and get_site_metadata to site-metadata. Stop calling today_deals; use today-deals, and update today-deals response consumers to read product rows from product_id while no longer depending on removed source_url / source_api_url fields. MCP clients that cached the removed Today Deals alias tool ohouse_deals__today_deals_legacy must switch to the retained canonical Today Deals tool ohouse_deals__today_deals. Replace public product inputs goods_id and production_id with product_id. Remove search/browse affect fields from requests; APIFuse sets required Ohouse ceremony values privately. Replace product coupon { target_type: "product", id } with { product_id }, and deal coupon { target_type: "deal", id } with deal-coupons { deal_id }. Replace exhibition { detail_id, section_id } with semantic { section }. Read shipping from shipping.method and shipping.service_level instead of method/service code fields. Read product rows from product_id, review counts from summary.rating_counts[], question totals from summary.total_count, and stop depending on source_url or source_api_url in normal outputs.
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.
Replace CatchTable search/shop output reads from camelCase fields such as shopRef, shopName, foodKind, avgRating, reviewCount, waitingAvailable, and waitingCount with shop_ref, shop_name, food_kind, average_rating, review_count, and waiting_discovery_hint. Replace my-status reads from activeWaitings, reservationRef, waitingRef, shopName, visitDate, visitTime, personCount, and waitingOrder with active_waitings, reservation_ref, waiting_ref, shop_name, visit_date, visit_time, person_count, and waiting_order. For waiting-info, read waiting_tables[].table_ref and waiting_tables[].label instead of tables[].table_id and tables[].name, and read person_option_summary instead of raw person_options. Call register-waiting with waiting_choice and optional menu_choices; do not pass raw table_id, person_options, or order.order_line_items.
This change tracks upstream schema drift in Daangn's realty GraphQL surface. All modifications are additive except the source rename on complex listing articles.
CatchTable unauthenticated availability now marks reservation option inspection as authentication-required instead of implying that create is known safe from time slots alone.
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.
Update callers from /v1/kakaomap-api/<operation> or kakaomap-api/<operation> to /v1/kakaomap/<operation> or kakaomap/<operation>. Operation payload schemas, auth mode, and behavior are unchanged.
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.
Update callers to send KMA baseDate and School Lunch mealDate as YYYY-MM-DD, KMA baseTime as HH:mm, KMA tmFc as an ISO 8601 datetime with timezone, and K-Startup announcement date filters as YYYY-MM-DD. Update response consumers to read Food Safety registered_date, KMA forecast date/time, K-Startup application dates, Law date fields, Naver Blog postdate, Naver Flight segment date, and School Lunch founded_date/meal_date as ISO YYYY-MM-DD or HH:mm rather than compact upstream strings.
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
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.
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.
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 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.
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.
Callers should read notice_id, ccr_cnnt_sys_ds_cd, and spl_inf_tp_cd from the selected lh-notice/list item, then call lh-notice/detail with panId=notice_id, ccrCnntSysDsCd=ccr_cnnt_sys_ds_cd, and splInfTpCd=spl_inf_tp_cd. Callers that need title, status, category, region, posted_date, closing_date, or detail_url should keep those fields from the selected list item. lh-notice/detail.notice now contains only notice_id, ccr_cnnt_sys_ds_cd, and spl_inf_tp_cd because the upstream LH detail endpoint does not reliably return the public notice summary.
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.
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.
Yogiyo clients should refresh restaurant-full before constructing carts, use only visible menu_sections, and avoid items/options with web_order_unavailable_reason. Show order-preview.display to users before calling place-order, check can_place_order=true and blockers=[] before submission, and treat price_breakdown/price_lines as validation details rather than the primary UI. Remove safety_number from place-order requests; guest remote orders always use safety number and NaverPay. place-order responses now include display, payment_method=NAVERPAY, payment_method_label, price_breakdown, and price_lines alongside payment_url.
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.
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 mirrors the current Modu Parking frontend payment request shape more closely:
Send shared-parking using_time from check-availability slots[].using_time_minutes. Decimal digit strings are still accepted for compatibility, but booleans, arrays, exponent strings, and empty values are rejected. If you have a Modu webapp guestSeq from URL/storage, pass it as guest_seq; otherwise the operation uses the current webapp default of 0.
modu-parking/start-payment now supports generating multiple supported payment gateway URLs from the same verified SMS session.
To create both payment URLs after one SMS verification, call start-payment once with pg_types set to ["naverpay","nicepay"]. Existing single-gateway calls with pg_type, or with pg_type omitted for the default NicePay URL, continue to work.
modu-parking/start-payment now fail-closes on the same live availability conditions that the Modu Parking frontend uses before payment:
For ticket payments, pass price or total_price, point, predict_begin_time, and predict_end_time copied from parking-detail.available_days and price_info. For shared parking, pass using_time and price from check-availability, but treat those values as current duration/price candidates rather than a reservation. start-payment now fails before SMS verification when the selected ticket or shared slot is stale, and returns NOT_PURCHASABLE with upstream diagnostics if Modu rejects final shared payment URL creation because the space is full or already in use.
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.
Stop sending pg_types. Send a single pg_type value (nicepay, naverpay, or mobilians) when a specific gateway is needed; when omitted, start-payment follows the current Modu webapp default of nicepay. Shared-parking callers must pass price or total_price from check-availability. Use separate start-payment/SMS attempts when you need to validate multiple payment gateways.
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 clients should follow search-parking item routing: parking_kind=\"ticket\" uses parking-detail(ticket_id), while parking_kind=\"shared\" skips parking-detail and calls check-availability(share_seq). start-payment now requires car_number, and shared payments must pass using_time copied from check-availability; arbitrary payment fields are rejected. Yogiyo order-preview and place-order items must contain only restaurant-full ids: item_id, category_id, quantity 1-99, and options with section_id/option_id; do not include names, prices, display labels, or other invented fields.
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.
KakaoMap search callers must treat place_url as optional and use confirm_id/name/address for selection when upstream omits a place URL. Modu Parking search callers should choose follow-up calls from ticket_id/share_seq evidence; generated search metadata no longer carries synthetic parking_kind/next_tool hints. Modu Parking parking-detail callers must provide ticket_id, check-availability callers must provide share_seq, and start-payment callers must provide using_time, point, and price or total_price explicitly for shared parking flows. Yogiyo find-restaurants and restaurant-full callers must treat rating, review_count, delivery_fee, delivery time range, free delivery threshold, open_status_code, menu names, menu prices, menu descriptions, option names, option prices, and below_minimum_order_allowed as optional unless the upstream branch actually returned those signals. Yogiyo order-preview callers must provide shop_id and at least one item explicitly; Yogiyo place-order callers must treat order_number and store_name as optional when Yogiyo's order submit response omits them. Do not rely on APIFuse defaulting absent counts, fees, names, or prices to 0 or an empty/placeholder string.
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.
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.
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.
Stop creating or passing Yogiyo APIFuse Connections. Call yogiyo/verify-phone without X-ApiFuse-Connection-Id, persist the returned opaque yogiyo_session_id only for the current checkout attempt, then pass that id to yogiyo/confirm-phone and yogiyo/place-order. If the session expires, restart at verify-phone. Read operations remain connection-free.
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.
Use one of the documented CatchTable table type codes (_ALL_, H, R, T, B, W, D, N) for catchtable/availability and catchtable/reserve. If catchtable/reserve returns TABLE_SELECTION_REQUIRED, retry with one of the concrete table type codes listed in the error message; do not retry by guessing from failed reserve attempts.
The operation API path and response contract are unchanged. This only disambiguates the generated MCP/developer metadata for the legacy alias.
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.
Existing ohouse/today-deals callers should regression-test strict response-schema assumptions because the operation now prefers the stable feed API, returns stronger product identifiers when upstream exposes them, and adds source API metadata. Callers that only read prior deal fields such as title, brand, URL, price, discounts, reviews, free_delivery, sold_out, and source_url remain supported. New operations are additive.
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.
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.
Update callers to send exact documented wire formats. CatchTable reservation dates and returned availability date_slots use YYYY-MM-DD, and reservation times use HH:MM such as 19:00, not 1900 or 7pm. KakaoMap transit times and KMA base times must use compact HHmm. Naver Map and Modu Parking prediction datetimes must include an ISO 8601 timezone. Naver Flight dates must use YYYY-MM-DD. KakaoMap car priority and transit sort must use the documented enum values.
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.
Existing daiso/products callers should verify response mappings against the renewed FindStoreGoods-backed schema and prefer the new grouped operations when they need details, reviews, stores, inventory, or catalog fanout.
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.
KakaoMap transit-info callers should read the documented bus-stop, bus-line, or subway-station branch fields under info instead of relying on arbitrary upstream raw fields.
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.
Update callers to send only documented enum values for closed domains. Yogiyo search sort must be one of recommended, rating, distance, delivery_fee, or delivery_time; Yogiyo place-order reports NAVER_PAY as the payment gateway; Catchtable action-result statuses are the documented successful terminal status for that action; Delivery carrier country codes are lowercase ISO 3166-1 alpha-2 values.
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.
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.
Daiso inventory callers should migrate from the previous unsupported inventory response contract to the new pickup-stock response fields: selected_store, retrieval_status, stores[].in_stock, stores[].quantity, and stores[].inventory_label. New Market Kurly, Daangn, Danawa, and Ohouse operations are additive public read tools and require no migration.
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 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.