content_settings_get

The article_product_*, CREATE_ARTICLE_CATALOG, DELETE_ARTICLE_CATALOG and other existing action/confirmation names remain compatibility identifiers; they do not restrict those shared functions to Article. Article manager-comment notifications, category controls, conversion and assignment remain Article-only. Timeline timeline_notifications reads its two post-create events, with no save or mutation revision. Source commit references below record introduction history; current support follows this family policy.

Read stored settings and available controls, prepare original-article manager-comment notification preferences, or inspect shared Article/Timeline POST catalog access, individual pricing, catalog details, creation options and filtered catalog pages, or prepare their app-unlock product creation/editing.

Read the shared content contract for authorization, app identity, result interpretation and recovery.

Inputs and output

For ordinary settings, require channelCode and pAppCode without view, pagination or mutation fields. The separate catalog and manager-comment notification views below use alternative strict inputs. The result CONTENT_SETTINGS supplies revision and a settings object keyed by public control names. Each entry includes value, description and its schema. Use those names and choices with content_settings_apply, not internal UX configuration keys.

A null value means the source response omitted that key. It is not an inferred default or a request to clear the setting. Outlink and welcome settings pages are version-only and therefore return no editable controls; use their content editor instead. Article category-tab visibility uses the fresh published-category prerequisite described below.

Controls cover timeline writing/reactions/tabs; notice pinning/comments/titles/page size; board social options/guidelines/page size; inquiry guidelines; question title/moderation; article tabs/protection/comments; photobook tabs/watermark/zoom; resource tabs/comments. Controls vary by app and exact installed instance. The read changes no configuration and creates no task. Returned schemas describe accepted input, not demonstrated browser or visitor behavior.

Read-only article appearance

The ordinary article settings response also includes readOnlySettings: 19 stored values for heading size/alignment, byline/credit, related widgets, share buttons and content-image width. Every entry has present, value and writable:false. False and empty strings remain real observed values; an absent key remains present:false,value:null, without pretending that a frontend default was stored. Unrelated unknown configuration is not exposed. These names are not accepted by content_settings_apply; the existing writable settings object is unchanged.

Input example

This is an input illustration, not a recorded call. Replace the channel, app, observed IDs and all-zero revision with values from the matching authorized read. A dry run does not save changes.

{
  "channelCode": "selected-channel",
  "pAppCode": "A00002"
}

Article category-tab prerequisite

The reader queries a complete current published-category inventory; missing discovery, malformed/partial lists or unpublished rows in that filter fail explicitly. canChangeVisibility is true only when a published category exists; categoryVisibilityEditorAvailable remains false.

hideCategories:false shows the tab; true hides it. Both changes require that fresh prerequisite, and the last visible visitor tab cannot be removed. New taxonomy categories are unpublished; creating one does not satisfy this requirement. Settings get does not add a publication editor or imply that a URL cover has been uploaded/rendered.

Illustrative article settings read:

{
  "channelCode": "selected-channel",
  "pAppCode": "B00001"
}

Article catalog membership views

This slice is OWNER-only and limited to B00001/B9xx01 or A00001/A9xx01. General pApp permission does not grant delegate access to catalog monetization. Photobook, resource and SERIES catalogs are not admitted to membership editing.

catalogId is the observed catalog business ccid, not its numeric row ID. It accepts 1–128 ASCII letters, digits, underscores or hyphens. Membership choices use their business mid. The reader verifies numeric/business identity, exact channel/consumer, POST pricing/targets and that every connection matches a current channel candidate. Complete stable pages of 100 are required internally; caller pagination is not accepted. Bridge bounds are 2000 catalogs, 2000 candidates/connections and 200 target contents. These are not all source product maxima.

The detail revision binds inventory/detail, connections, candidates, existing individual price and target contents. Use it only with the catalog action; ordinary app-settings revisions are not interchangeable. A null individualPricing means no observed individual price, not authorization to invent or change one. These reads do not enroll subscribers, change prices or establish visitor entitlement.

The closed checker retains OWNER-only access. The shared authorization/connection lock, current credential/profile and exact installed-instance lookup apply before transport, with authentication checked again afterwards and the domain rechecking context around every call. Requests use the selected channel header; the exact consumer is a query only on routes that require it, not on candidate/target queries. GET requires 200/data and link/unlink 204/none; redirects and automatic POST retries are disallowed. These are connected source contracts, not newly observed actual responses. Older hosts without the port still return CONTENT_CATALOG_TRANSPORT_REQUIRED with no write. Destinations are the exact article catalog list and selected catalog's pricing-policy/connect-membership screen; use validated returned navigation.

Illustrative selection input; host integration is still required:

{
  "channelCode": "selected-channel",
  "pAppCode": "B00001",
  "view": {"kind": "catalogs"}
}

Illustrative selected POST catalog read; replace the business ID with a discovered value:

{
  "channelCode": "selected-channel",
  "pAppCode": "B00001",
  "view": {"kind": "catalog_memberships", "catalogId": "observed_catalog_ccid"}
}

Original article individual pricing

This option supports the exact installed article or timeline instance (B00001/B9xx01 or A00001/A9xx01) and OWNER role only. Installed aliases keep their exact identity for pricing and all shared catalog/product actions. Use view:{kind:catalogs} to select an existing POST catalog, then pass its business ccid, not a numeric row ID. No caller pagination or other view selectors are accepted in this pricing view.

CONTENT_CATALOG_PRICING returns catalog, catalogs, connectedMemberships, candidates, individualPricing, targets, linked post details, pricingInfo, priceLimits and revision, with writesPerformed:false. The complete catalog/membership inventories and target-to-post relationships must agree; bounds remain 2000 catalogs/memberships and 200 targets. These reads are not an atomic backend snapshot. individualPricing:null means no current observed individual price; save may create one after fresh validation, while discard requires an existing price.

pricingInfo contains the freshly bound KRW/USD channel currency and branding status. priceLimits supplies the applicable currency minimum, maximum, unit, allowed periods and pointPurchaseVerified. Use these returned limits rather than membership-product limits or a value inferred from the app code. Catalog and monetary contexts must agree on the connection, credential version, seller, role and channel ID/code/title, with checks after the reads.

Preparation uses the common point-store readiness reader in discover mode. Two successful explicit false/null store summaries report not_configured and allow CASH_ONLY; configured stores require valid branding and stable reread. CASH_AND_CP needs verified branding with positive ratios. Missing, malformed, authentication, permission, route and transport failures remain errors, never evidence of disabled points. Missing common readers or catalog transport returns CONTENT_CATALOG_TRANSPORT_REQUIRED. This read does not create branding or grant delegate access.

individualPricing retains the raw channelPointAmount and originalChannelPointAmount in stored CP units. The original USD edit/display code formats raw stored amounts without an evident inverse conversion. Do not present raw CP as dollars or claim same-screen price parity until an actual same-target console comparison resolves that discrepancy.

This source uses the existing contentCatalogRequest, monetizationContext and readPointBranding connections, including their hosted authorization proxy; no extra Core hook, transport, endpoint input or origin is required. Successful navigation identifies the selected app catalog's pricing-policy/individual-pricing screen with catalogView:pricing. Use the returned link.

Illustrative read only; replace the channel and catalog with authorized discovered values:

{"channelCode":"selected-channel","pAppCode":"B00001","view":{"kind":"catalog_pricing","catalogId":"observed_catalog_ccid"}}

Original article catalog details

Discover an existing POST catalog with the catalogs view and pass its business ccid. Unsupported app families return CONTENT_CATALOG_DETAILS_UNSUPPORTED; selected supported aliases are never remapped.

CONTENT_CATALOG_DETAILS returns the complete catalog list/detail, connected memberships and candidates, individual price, target rows and linked posts, with a revision and writesPerformed:false. The same 2000-catalog/membership and 200-target bounds and bidirectional target/post consistency checks apply. This view does not request currency or point branding because it does not edit pricing. Use its revision for one title or active-state change, not an ordinary settings revision. The catalog_delete action also requires this fresh catalog_details revision, including the linked-post snapshot; it adds no deletion-specific read view.

The existing common catalog transport and hosted routing are connected. The exact returned destination is the selected app catalog detail page under monetization/catalogs/{ccid}, bound to content-catalog, catalogId and catalogView:details. It is distinct from the membership and individual-pricing subpages.

Illustrative read; replace the channel and catalog with discovered authorized values:

{"channelCode":"selected-channel","pAppCode":"B00001","view":{"kind":"catalog_details","catalogId":"observed_catalog_ccid"}}

Original article catalog creation options

It requires OWNER and the exact installed article or timeline instance (B00001/B9xx01 or A00001/A9xx01). Aliases are not remapped. Supply channelCode, pAppCode and this view only; there is no existing catalogId, caller pagination or target-model selector.

CONTENT_CATALOG_CREATION_OPTIONS returns catalogs, candidates, pricingInfo, priceLimits, revision and writesPerformed:false. The complete inventories contain at most 2000 catalogs and 2000 channel membership candidates. Membership choices use their observed business mid, not a numeric row ID. Creation requires fewer than 2000 existing catalogs so the resulting inventory still fits the bound. The read is not an atomic snapshot and creates no task or catalog.

The revision binds the current connection/context, catalog inventory, membership candidates, currency and branding. Pass this revision as expectedRevision to catalog_create; an existing catalog's detail, membership or pricing revision is not interchangeable. Fresh common channel-currency and point-readiness reads are required even for membership-only creation. Explicit disabled setup permits cash preparation; invalid configured branding and transport/authentication failures remain errors. Currency in a catalog price input is optional because this preparation already supplies the channel value. The individual-price rules, including returned currency limits and verified branding for CASH_AND_CP, apply when selecting pricing.

The source reuses the connected common catalog, currency and branding ports and the existing hosted authorization path. Its validated destination is the selected channel's exact selected app monetization/catalogs/create screen, with catalogView:creation and no catalogId. The later created result identifies its own detail screen.

Illustrative creation-options read; replace the channel with the authorized selection:

{"channelCode":"selected-channel","pAppCode":"B00001","view":{"kind":"catalog_creation"}}

Original article catalog search

It requires OWNER and the exact installed article or timeline instance (B00001/B9xx01 or A00001/A9xx01). Both supported families and their installed aliases use this filtered view. The original catalogs view still reads a complete unfiltered inventory; catalog_search returns one selected API page.

Supply channelCode, pAppCode and view. There is no caller sort, target-model filter, selected catalogId or mutation field. Page sizes match the original console; the maximum page and search length are bridge input bounds, not claimed console limits. Search matching and ordering belong to the upstream API. The bridge neither invents a title-only matcher nor reorders the result locally.

CONTENT_CATALOG_SEARCH returns catalogs in API order, catalogSearch with the resolved selection, catalogPagination:{page,limit,total}, completeInventory and writesPerformed:false. Response page/limit must exactly match the requested values. Row count must match the observed total and page size; duplicate numeric IDs/business ccids, mismatched scope or rows contradicting an explicit isActive filter are rejected. An out-of-range page may validly return an empty list with its observed total rather than silently changing the requested page.

completeInventory is true only for page 1 when its row count equals the filtered total, including zero results. It does not turn a filtered page into the complete unfiltered mutation snapshot or establish atomicity. This read creates no saved task and returns no mutation revision. Select the observed business ccid of a catalog supported by the intended action, then read catalog_details or the matching membership/content/pricing view before changing it; existing catalog mutations require a POST target. Even completeInventory:true cannot replace that fresh read.

Current navigation preserves the selected app and observed query for an in-range catalog search. An out-of-range result uses consoleDestination:parent with instructions to reselect conditions. Follow the returned validated link; do not construct a replacement.

This option requests no new value and performs no write or restoration. Bulk activation and the existing upload HOLD remain separate.

Illustrative default first-page read:

{"channelCode":"selected-channel","pAppCode":"B00001","view":{"kind":"catalog_search"}}

Illustrative second page of inactive results, with an upstream search term. These are example conditions, not observed catalog data:

{"channelCode":"selected-channel","pAppCode":"B00001","view":{"kind":"catalog_search","page":2,"limit":30,"search":"Premium","isActive":false}}

Original article product preparation

These options require OWNER and the exact installed article or timeline instance (B00001/B9xx01 or A00001/A9xx01). B9xx01 aliases are not remapped; delegate product configuration remains unavailable. The existing common catalog, channel-currency and branding readers are reused.

Supply channelCode, pAppCode and the exact view object. These views accept no caller pagination, search, fields, settings or action. productId is the numeric product identity, not its distinctId, a membership mid or catalog ccid. The existing article_products paged read and article_product detail read can help identify a product but do not supply a mutation revision. Read article_product_edit before saving; use article_product_creation for creation.

Preparation reads every product page at 100 rows, up to 20 pages/2000 products. Every page must match its requested pagination, total and expected row count, with unique numeric IDs and distinctIds. Optional returned channel/consumer fields must match the selected instance. Editing additionally requires exact list/detail agreement. An apply that creates a product needs fewer than 2000 existing rows so the resulting inventory fits. Reads are sequential, not an atomic snapshot.

The revision covers the bound context, complete sorted inventory, selected detail when editing, and current currency/branding. Context includes the connection, credentials, actor/channel and installed app. Changed inventory, target, currency or branding requires a new matching preparation. Successful reads return writesPerformed:false and create no task. Missing transport/readers fails with CONTENT_CATALOG_TRANSPORT_REQUIRED; incomplete or inconsistent source data cannot become a mutation plan.

inputLimits reports nameAndPresentationalNameUtf16, currency, createSellingMin, maxPrice, createSellingUnit, originalPriceDecimalPlaces, editOriginalMinimum, expiryPeriods, pointPurchaseVerified, creationDefaults, editReadOnlyFields and inventoryBound. Use the returned limits and product price rules. The advertised creation defaults are isDeactivated:true, expiryPeriodInDays:15 and CASH_ONLY; they are guidance, not omitted-field defaults in the strict apply input. Explicitly supply the required fields. Currency is an optional consistency assertion for creation/editing; omission uses this freshly verified channel currency.

Amounts remain strings in the channel's KRW/USD currency, with no catalog CP conversion. Missing purchase-method metadata stays absent in observations; the writer requires an explicit choice rather than silently supplying a default. Point readiness is discovered from the explicit store summary. Disabled setup is not_configured and permits cash; a configured store needs valid branding. CASH_AND_CP requires verified branding. Malformed configured data, failed requests and changed context remain errors.

Creation preparation opens the surviving product list and tells the human to use its create button to open the modal. The URL does not open or prefill that modal. Editing opens the exact product editor. Use the returned destination; do not construct a create route. Neither link proves a save.

Complete creation preparation with an illustrative channel:

{
  "channelCode": "selected-channel",
  "pAppCode": "B00001",
  "view": {
    "kind": "article_product_creation"
  }
}

Complete edit preparation; replace 123 with an observed numeric product ID:

{
  "channelCode": "selected-channel",
  "pAppCode": "B00001",
  "view": {
    "kind": "article_product_edit",
    "productId": 123
  }
}

These options configure product availability and payment choices; they do not purchase a product, assign subscribers, publish articles or verify visitor entitlement. Translation backlog, D-PLAN-1 and the existing upload HOLD remain separate.

Original article manager-comment notification preferences

This connects the existing settings methods and canonical recovery in source.

Use view.kind:article_manager_comment_notifications with the selected channelCode and exact article pAppCode:B00001/B9xx01. This option requires OWNER, one matching installed article app and the current channel-scoped authorization. DELEGATEE/CREATOR are not admitted; installed B9xx01 aliases retain their exact event and app identity. It is a separate view from ordinary app settings, comment enablement and catalog configuration; do not combine it with settings, catalog IDs, pagination or another view.

The view reads the one fixed event SELLER_P_APP_B00001_POST_MNG_COMMENT_CREATE. It requires exactly one existing complete configuration matching that event and channel. Missing, duplicate, foreign or malformed records are errors, never default preferences. A canonical positive numeric-string channel identity is normalized to a number. The complete record is bounded to 1 MiB for journaling; this is a bridge bound.

ARTICLE_MANAGER_COMMENT_NOTIFICATIONS returns revision, settings.active, storedDelivery (email, appPush, pwaPush, realtime), configurationId, eventKey, sourceControls and availableChanges.activate/deactivate. Each allowed choice shows noop and the four before/requested values through the transition projection. The EMAIL control is locked; no independent delivery edit is exposed. A choice can be disallowed with a reason when the existing receiver policy cannot be preserved.

Before a real change, the existing receiverType must be SELLER and uniReceiverTypes must be exactly [SOURCE_DETAIL_META_SUBSCRIBER_DISTINCT_ID]. A mismatched or missing receiver policy can remain readable; this control cannot repair or normalize it. isSendRealtime, the optional custom message key, identity and unknown business fields are preserved. Re-enabling ACTIVE does not restore delivery flags cleared by OFF.

Two identical complete reads and current context checks establish the preparation revision. This is sequential observation, not an atomic snapshot. The read performs no PUT, creates no saved task and does not resolve earlier uncertainty. Use this revision only with the matching notification action.

The shared hook uses the separately configured notification origin and the selected x-publ-channel-id. It sends only the source bulk GET /seller/api/v1/configurations/sending-configurations with eventKeys set to this one event. There is no fallback to the core/resource service, caller origin/header/credential input, consumer header or unrelated-event inspection. Missing host wiring or origin fails explicitly. The exact B00001 installation, credentials and hosted authorization are checked around transport; source connection does not prove actual service compatibility.

The returned exact destination /channels/{channelCode}/p-apps/B00001/notice is the manager-comment notification settings screen, not a notice-post editor. Follow the returned labeled link; this read creates no post, comment, message or notification and proves no delivery.

Illustrative read only; replace the channel with the authorized selection:

{"channelCode":"selected-channel","pAppCode":"B00001","view":{"kind":"article_manager_comment_notifications"}}