Edit a channel's advanced code

Use one get/apply workflow for CSS, head/body JavaScript and head HTML.

Read code and availability

Select the intended channel through the directory guide or the bound hosted resource. Call design_custom_code_get:

{"channelCode":"selected-channel-code"}

Inspect initialized, all four current code areas, revision and availability. Get performs no initialization or code write. Keep the current full source for any area you intend to edit: apply replaces the complete supplied area.

An OWNER/DELEGATEE account role, selected-channel credential and configured CHANNEL_ENV origin are required. JavaScript/HTML also require an eligible plan and returned ACTIVATED connected-domain metadata. availability.css:true is independent of that gate, but does not bypass authentication/context guards. Domain metadata alone does not prove DNS, HTTPS or rendering.

Plan only the intended edits

Pass the channel and revision just returned into design_custom_code_apply. For a CSS-only change, omit the three gated fields entirely:

{
  "requestId":"example-css-update-001",
  "channelCode":"selected-channel-code",
  "expectedRevision":"0000000000000000000000000000000000000000000000000000000000000000",
  "css":".site-title { letter-spacing: 0.02em; }",
  "dryRun":true
}

Replace the placeholders and supply the intended complete CSS. This example preserves both JavaScript areas and head HTML. Empty strings clear areas; they do not mean preserve. Including even an empty JavaScript/HTML field invokes that access gate. Pass JavaScript as raw source with ordinary JSON escaping; the bridge handles its storage escaping.

A new dry run checks the revision and availability and returns whether initialization is needed. It reports planned code groups when settings exist; otherwise those groups are deferred until real initialization. It creates no job. A repeated dry run for an existing task instead returns stored progress, without rereading code or availability.

Save and interpret completion

To execute the intended plan, preserve its request ID and business inputs and set dryRun:false. The workflow initializes missing shared settings, applies CSS if needed, then applies any combined JavaScript/HTML change. It preserves omitted code, rereads after writes and checks the final four-field state.

CUSTOM_CODE_APPLIED with confirmed custom_code_read means the expected stored state was observed. Saved code can take effect immediately; there is no separate publish call. changed:false can still follow initialization, and a completed replay returns saved historical code.

The writes are sequential. If CSS succeeds but the script write or renewed availability check fails, CSS can remain saved. The workflow provides no automatic rollback, and revisions are not atomic locks against external editors.

Inspect partial or uncertain work

Use the original task ID with task_status:

{"taskId":"example-css-update-001","taskType":"custom-code"}

Inspect phase, step states and the last result. If continuing the original operation is intended, use the same ID/type with task_resume. Preserve the original connection and inputs. A definitely rejected step can be attempted again after its cause is resolved; an uncertain step is observed first and is not resent while its result remains unknown. Do not change the ID to bypass that protection.

A saved completed result is historical even when apply/resume checks current channel context. Use get for present code and availability. Check visitor-facing behavior in a browser before relying on it.

Reference index · Code get · Code apply · Common results

Saved plan replay

For an existing matching task, dryRun returns historical saved plan/progress, with historical:true, replayed:true and false current verification. It performs no fresh business-state or eligibility check, no business effect and no journal change. Current console/action links are omitted. Follow nextStep for the same target's current state; keep the original task ID for uncertain-outcome recovery. Context and saved-input checks still apply. A new task follows normal fresh-plan validation; another request ID must not bypass an uncertain effect.

nextStep uses design_custom_code_get with the original channelCode; existingPhase and per-step code/state remain saved data. Reading history does not execute stored code.

Saved record identity

For this workflow, existing apply/dry-run calls and task status/resume require both the saved task ID and saved input requestId to match the requested ID. A mismatching or malformed saved identity returns TASK_STATE_UNVERIFIED before workflow context or business-state reads. Preserve the original record for inspection; do not rename/edit it, try its embedded ID or create a replacement request to bypass the error. No stored record is repaired or resent. Valid matching records retain the recovery behavior described above.