# Channel Point reads, configuration and human actions
[channel_points_get](../tools/publ_channel_points_get.md) selects policy, products, setup presets, a product, issuance/records, WEB ledger/history or withdrawals/detail. OWNER or explicit MANAGE_MONETIZATION delegation is required.
Use current discovery, choose the exact view, retain raw_CP and source monetary strings, and report coverage. Source errors, missing branding and malformed records do not mean inactive points, an empty inventory or a zero balance. The policy/products views keep their narrower observation flags; new finance views use CHANNEL_POINT_SCREEN. The products view repeats the exact page and returns productsRevision only for a valid page; selected product detail also verifies repeated parent/detail observations. Do not apply one view's confirmation scope to another.
| Data | Source service / route under /seller/api/v1/ | Binding and boundary |
| --- | --- | --- |
| Branding, configuration, policy and WEB products | Core channel-management/in-channel-store/branded-point-system/ | Original stored settings/list views. |
| Setup preset | Core branded-point-system/preset under the same prefix | No branding read or activation inference. |
| Product detail | Core branded-point-system/point-products/{publProductId} | target_platform=WEB; must match observed parent page. |
| Ledger/history | Core branded-point-system/ledgers/web and ledger-transaction-records | WEB and base currency; history page/limit, inserted_at descending. |
| Withdrawals/detail | Core branded-point-system/ledger-withdrawal-tickets[/ticketId] | WEB, masked account number, stable parent/list/detail agreement. |
| Issuance | Separate POINT channel-point-management/issuance-summary | Operator-configured separate origin; no core fallback. |
| Issuance/consumption records | Separate POINT channel-point-management/issuance-records or consumption-records | Unpaged source capped at 2 MiB/1,000 rows, returned subset at most 100; no CSV or complete inventory claim. |
All reader finance transport calls are GET. Reads and console handoffs change no policy, products, balances or bank details; the supported configuration writers below have separate write and recovery contracts. setup-options can be observed without establishing whether the channel has completed setup.
The console prefix is /channels/{code}/monetization/channel-point/. Destinations are point-issuance-status, policy-setting, policy-setting/provision/edit, charge-products, withdrawal-request, withdrawal-request/history and withdrawal-processing-history[/ticketId]. Product editors and onboarding open within their source containers; no invented edit/create URL is used. After the person acts, reread the corresponding view. There is no point-finance task type, financial replay or automatic traversal. Configuration tasks are separate: point-settings, point-provisions and point-products.
Withdrawal uses POINT_WITHDRAWAL_CONSOLE_REQUIRED; the other four use POINT_CONSOLE_REQUIRED. They preserve prerequisiteError.code and mark eligibility:not-observed / prerequisitesObserved:false without projecting partial data or submitting changes. Selected-product actions and revise-withdrawal retain their identity checks and have no such fallback. Read the [handoff contract](../tools/publ_channel_points_handoff.md) for the exact error allowlist.
## Product-list page navigation
The `products` result includes `consoleView` with the destination `page`, `limit`
and `exactMatch`. Valid pages preserve the API selection in the single console URL.
For a page beyond the observed total, the bridge opens a known first-list parent
at page1/limit15 with `exactMatch:false` and a navigation notice. The source has both
a last-page effect and a first-page invalid-page redirect; their actual rendering
order is not inferred. Returned API `productQuery`, `pagination`, empty records and
coverage are unchanged; the parent link must not be presented as the same returned
empty API page. Re-select a page in the console if needed.
Navigation validates the selected WEB query, row count and unique identities,
pagination, coverage, verification and exact URL. A substituted page/filter/target
or missing evidence produces no destination. This does not change source requests,
product prices/state, branding checks, role/scope rules or financial actions.
Policy and the separate product-detail/financial views keep their own contracts.
Actual console click-through and populated service observations remain separate.
## Finance page and selected-record navigation
Successful finance reads keep the existing string `view` and additionally return
normalized `selection`. Successful observed human handoffs return their normalized
action as `selection`; unavailable-prerequisite fallbacks retain their prior shape.
`ledger-history` and `withdrawals` preserve the requested page and limit in the
single console address. Their `consoleView` reports the destination page, limit
and `exactMatch`. An empty API page beyond the observed total keeps its original
pagination and records while navigation explicitly opens the first parent list
at page1/limit15 with `exactMatch:false`. It is not the returned empty API page.
An empty first page remains an exact list destination. No second page is fetched.
Selected `product` reads and edit/activate/deactivate/delete-product handoffs keep
the verified parent page/limit. Their navigation relation is `parent` even when
that list page matches exactly: select the observed product row to open its editor.
No product modal deep link or completed financial action is inferred.
`withdrawal-detail` and revise-withdrawal instead open the exact observed ticket
route with target navigation and no list queries. Bank masking remains in place;
source bank-edit availability still depends on REQUESTED status.
The navigation boundary binds normalized selection, page/count/coverage, row identity, financial currency and the selected product or ticket projection. Mismatched selection, target, page, verification or destination suppresses the address. Unselected human destinations and missing-prerequisite fallbacks retain their existing source screens and financial-action boundaries.
## Editable policy switches
`channel_points_get` policy now returns `configurationRevision`. Use [`channel_point_settings_apply`](../tools/channel_point_settings_apply.md) for individual-content point priority and purchase-based restriction resolution. The other three source-disabled switches are preserved. This supersedes older blanket settings-handoff statements in this document; onboarding, products, and financial actions remain separate boundaries. Localized provision editing is described below.
## Human-reviewed point provisions
The policy read now also returns `provisionsRevision` and the four editable localized refund/usage field names. Use the existing [`channel_point_settings_apply`](../tools/channel_point_settings_apply.md) with `provisions` instead of `settings`, dry-run the complete resulting text, and obtain human review before passing its `contentHash` as `humanReviewedContentHash`. Common/redemption policies and configuration remain unchanged. The writer validates the receipt and independent readback, with read-only `point-provisions` task recovery and no repeated uncertain POST. This supersedes older provision-editing handoff-only statements; actual-service mutation, same-screen captures and restoration are still unverified.
## Existing charge-product changes
The products view now repeats its exact WEB page and returns `productsRevision`
only for a valid source page. Use
[`channel_point_product_apply`](../tools/channel_point_product_apply.md) to edit
the source display name/bonus or selected product visibility. The method preserves
price/base quantities and unrelated rows, refuses forced-visible hiding, checks
independent readback, and never repeats an uncertain source request. Recovery uses
`point-products`. The console address preserves the page/limit; edit opens the
observed parent list modal entry. Initial product creation and deletion are not
implemented here. This supersedes older existing-product handoff-only statements;
actual mutation, restoration and original-console capture pairs remain pending.
