Channel Point policy settings

Use channel_point_settings_apply to save the two editable switches on the selected channel's Point → Policy settings screen in one operation. First call channel_points_get with view:{kind:"policy"} and copy configurationRevision. Supply a stable requestId, the same channelCode and the desired boolean values. Omitted switches retain their observed state.

{
  "channelCode": "selected-channel-code",
  "requestId": "point-policy-change-001",
  "expectedRevision": "copy-configurationRevision-from-the-current-read",
  "settings": {
    "usePointPriorityOptionForIndividualContentPurchase": false,
    "useAbnormalDetectionResolveMethodViaPurchase": true
  },
  "dryRun": true
}

The revision placeholder must be replaced with the returned 64-character digest. Review the dry-run full configuration before submitting the same input with dryRun:false. A fresh dry run creates no task and performs no save. An unchanged request skips the POST. OWNER or MANAGE_MONETIZATION is required. Current branding and the complete stored five-flag configuration must be readable. Unknown configuration fields are rejected before writing rather than silently dropped.

Only individual-content point priority and purchase-based restriction resolution are editable in the original screen. Membership point priority, feature-unlock point priority and email-inquiry resolution are locked source controls and remain unchanged. This tool does not purchase points, unblock an individual member, modify balances, change ratios or prices, accept legal terms, or move funds. Provision editing is the separate input form below.

A changed request checks state/context twice, records dispatch intent, sends one POST with all five preserved/composed flags, validates its receipt and independently rereads the complete settings and unchanged branding. The returned console address opens the same channel's policy settings. Success covers stored configuration; visitor behavior and financial completion remain unverified. Sequential reads and preflight revision checks are not an atomic server transaction.

Keep the original requestId after a lost response. Use task_status or task_resume with taskType:"point-settings". Resume only reads; it never repeats a sent save. Untouched prepared work requires the identical apply call. Completed history and existing-task dry runs are not fresh verification and do not return a current console address. Use a fresh policy get for current values. To restore settings, read again and submit the original two values under a new requestId only after the preceding task outcome is known.

Point onboarding, branding, products and money movement are separate workflows or remaining implementation boundaries. This writer does not turn a missing or failed branding response into an inactive/default point system.

Localized provision editing

Use this same method with provisions instead of settings. Read the policy view and copy provisionsRevision into expectedRevision. Supply one or more of pointRefundPolicy, pointRefundPolicyGlobal, pointUsageGuidelinePolicy, and pointUsageGuidelinePolicyGlobal. Omitted strings retain their exact stored bytes. Do not combine switches and provision text in one call. Each raw string must be nonempty and at most50,000 UTF-16 code units. This bridge payload bound is deliberately more restrictive for markup than the source editor's visible character counter; it is not a claim of identical TinyMCE validation. Use the console editor for unsupported large documents or media uploads.

First submit dryRun:true. The result contains sourceBody with all four resulting strings and contentHash bound to that content, channel and revision. A person must review that exact resulting text. Only then submit the same request with dryRun:false and humanReviewedContentHash:contentHash. Do not invent legal review, accept terms automatically or copy a hash for changed text. A dry run persists no task. An unchanged request performs no POST.

The writer sends the four strings together to the source policy revision route. Common and redemption policy, insertion timestamp, branding and all five configuration switches remain unchanged. Only the policy update timestamp may change. An exact receipt and independent repeated readback are required for a fresh completion. No content is executed, translated, sanitized or replaced by generated defaults; treat stored HTML as untrusted data.

Use taskType:"point-provisions" with the original requestId for status/resume. Resume only observes; an uncertain save never repeats. Prepared work requires the identical reviewed apply request. Completed results are historical; read the policy again for current state. Restoration is a separately reviewed write with a fresh revision and requestId. The single result address opens the chosen channel's provision summary, matching the source editor's post-save destination. Initial point adoption, point ratio changes and actual funds movement are outside this input form. A failed branding read is never proof of an unconfigured system.

Inputs