# Channel discovery, context, and archiving
Use account discovery to find a channel, channel context to confirm the intended target, and the archive workflow to change only its directory classification. These operations have different credential and hosted-resource requirements.
Current response compatibility follows the [source channel-code fallback](../reference/README.md#current-channel-directory-alias-compatibility), including explicit null legacy fields. It does not change inputs, normalized revisions or task recovery.
## Find a target
Call [channels_list](../tools/publ_channels_list.md):
```json
{"page":1,"limit":15,"markChannelAs":"RUNNING"}
```
Follow `nextPage` with the same filters and limit until you find the intended channel. Select by the returned identity, not title alone. Use `NO_INTEREST` to read archived channels. `RUNNING` is a list classification; actual lifecycle state is separate. An incomplete or malformed page is an error, not evidence that the account has no channels.
`credentialPresent:true` means a credential entry exists locally. To work inside the selected channel, call [channel_context_get](../tools/publ_channel_context_get.md) with its actual returned code:
```json
{"channelCode":"selected-channel-code"}
```
The context result confirms that matching channel detail was read with its credential. Its role/permissions are descriptive claims and do not verify all workflow permissions. Keep supplying the explicit channel code in each subsequent tool; no shared current channel is switched.
On hosted connections, the account resource exposes directory/archiving tools, while a separately authorized selected-channel resource exposes the context read. Follow the hosted dashboard's resource selection and each connection's actual discovery. The account list's suggested next step cannot cross this boundary by itself. Missing credentials require a human connection repair, never passwords or tokens in chat. A changed connection identity can affect unfinished jobs.
## Archive or unarchive
For each chosen row, copy the current `channelCode` and `revision`. Prepare [channels_mark_apply](../tools/publ_channels_mark_apply.md) with a unique request ID, 1–50 targets in the intended order, the desired `markChannelAs`, and `dryRun:true`. The tool page includes the full input shape.
Inspect the new plan's target titles, `from`, `to`, `writeNeeded`, and `impact`. Execute with the same request ID and business inputs, changing only `dryRun` to `false`. The account token is sufficient for this directory operation; channel context is needed for channel workflows, not a prerequisite to archive a listed row.
A verified completion is `CHANNEL_MARK_APPLIED`, `phase:done`, and the expected completed/target counts. The workflow reads both classifications completely, checks selected revisions and checkpoints, and verifies their final values. A target already in the requested classification counts as completed without a write. No site deletion, deactivation, publication change, or payment cancellation follows from this result.
To unarchive later, read `NO_INTEREST` again, use those fresh revisions in a new `RUNNING` request, and inspect its plan. Unarchiving does not relaunch or reactivate a site.
## Inspect an interrupted batch
Call [task_status](../tools/publ_task_status.md) with the actual original ID:
```json
{"taskId":"example-channel-archive-001","taskType":"channel-archive"}
```
If continuing the saved operation is intended, pass the same ID/type to [task_resume](../tools/publ_task_resume.md). Resume can perform remaining writes. The directory reads' `taskType:channel-directory` is not a supported recovery type.
`prepared` can proceed after revalidation. `sent` observes the uncertain change without replaying its POST; only a matching selected-target checkpoint permits progress. A later failure leaves earlier changes applied, with no automatic rollback. Keep the original request ID after interruption; a new ID must not be used to force a retry. A `done` replay returns history, so use a fresh list for current state.
## Operational boundaries
Archive planning/execution reads both complete account lists in pages of 100 and supports at most 5,000 combined rows. Concurrent total changes or duplicate identities stop it. The final comparison covers selected rows; it is not an atomic server transaction or a preservation check of every unselected channel. A successful readback does not prove browser behavior, live multi-user isolation, or causal attribution to this task alone.
[Reference index](../index.md) · [Common results](../reference/results.md) · [Hosted discovery](../tools/publ_screens_list.md#hosted-resource-scope)
## Exact channel-list destination
The response's `selection` preserves the normalized API request; `filters` and
`pagination` keep their existing meanings. `consoleView` contains `exactMatch`,
`page`, `limit`, `markChannelAs` and `omitted`. It describes the browser destination,
not a replacement for the API selection.
The original AllChannels screen accepts page sizes 15, 30, 50 and 100 and reads
`page`, `limit` and `markChannelAs`. Without installed-feature filters, the single
URL preserves that exact selection, using the central console origin. If the API
request uses another valid size or nonempty `installedPAppCodes`, the URL opens
the same archive classification at page 1 with 15 rows. `consoleView.exactMatch`
is false, `omitted` identifies `installedPAppCodes` where applicable and
`pagination`, and navigation labels this as a broader parent list. The API result
still contains the originally requested page/filter. The bridge never fabricates
an unsupported UI filter query or claims that this broader list is the same result.
An empty out-of-range API page retains the existing successful-read contract and its requested page when representable; it is not evidence the account is empty.
## Archive-result destination
New plans and progress include the intended `markChannelAs`. A new `PLAN_READY`
and a freshly verified `CHANNEL_MARK_APPLIED` return one parent console link at
`/all-channels?page=1&limit=15&markChannelAs=<requested-classification>` through the
central console origin. A batch can span multiple pages, so this is its matching
classification's parent list, not a claim that every selected channel appears on
the first page. A plan has not saved the classification. Follow the current
directory pagination to find each selected identity after a completed operation.
Navigation validates the plan's target transitions or the completion's counts,
identities and classifications. Partial failures, uncertain outcomes and stored
history provide no current destination. Read progress and use the original task
for recovery; a missing link never permits resending an uncertain write. The
earlier saved-plan replay contract remains in force. No site launch, suspension,
publication, payment or deletion action follows from an archive classification.
## Saved record identity
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
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 record
is repaired or resent. Matching records retain their existing recovery and
freshness checks; this rule does not convert them into universally read-only calls.
