account_profile_apply — Save the owner account nickname

[Migration map](../reference/tool-name-migration.md).

# account_profile_apply — Save the owner account nickname

Save the account display nickname, read it back, refresh account credentials, and recheck the same owner and main profile. This does not rename a channel, change a login name, or edit another person's profile.

Requires an OWNER account connection. A channel manager connection cannot authorize this account screen. The source-defined hosted account resource admits this tool; a selected-channel resource does not. These are source scope rules, not deployed authorization or isolation evidence.

## Inputs

| Field | Required here | Contract |
| --- | --- | --- |
| `nickname` | Yes | string; min length 2; max length 20; pattern `^[ㄱ-ㅎㅏ-ㅣ가-힣A-Za-z0-9_]+$`; Account display nickname: 2–20 Korean letters or jamo, Latin letters, digits, or underscores; no spaces or leading/trailing underscore. This is not a channel title or login name. |
| `confirmToken` | No | string; pattern `^ct[a-f\d]{32}$`; The confirmToken from this tool's preview result. Omit it to preview; repeat the same input with it to execute. |

Unknown fields, arbitrary IDs, images, credentials, and demographic changes are rejected.

```json
{
  "requestId": "docs-account-profile-001",
  "expectedRevision": "0000000000000000000000000000000000000000000000000000000000000000",
  "nickname": "SiteOwner_2",
  "dryRun": true
}
```

The revision is scoped to this account screen; profile and contact revisions are not interchangeable. Reusing requestId with changed business input returns TASK_INPUT_CHANGED. A dry run on an existing matching task returns its historical plan and taskPhase, with planIsHistorical:true; it does not rebase the saved plan onto current values.

## Results

Replace the illustrative zero revision with the get response before calling. A new dry run returns PLAN_READY and creates no task. A real ACCOUNT_PROFILE_APPLIED response with verification.confirmed:true means the matching stored profile was observed after credential refresh. No-op changes skip both the PUT and refresh. Other profile fields are preserved.

## Next steps and limits

Keep taskId and taskType account-profile for `task_status` and `task_resume` described in the [agent guide](../agent-guide.md). Phases are prepared, sent, refreshing, and done. Unknown PUT or refresh outcomes are not resent. An explicitly classified not-sent/rejected PUT can restore prepared, while such a refresh failure can clear its sent marker. The original task can retry only after its identity, snapshot and stage checks; this is not an unconditional at-most-once promise for every error. ACCOUNT_REFRESH_OUTCOME_UNKNOWN requires trusted credential recovery for the original connection. A new login normally creates a new connection and does not automatically rebind old tasks. Completed replays are historical with verification.confirmed:false; use [get](publ_account_profile_get.md) for current data. There is no conditional server write, automatic rollback, or causal attribution.

[Account guide](../guides/account.md) · [Implementation contract](../core/account-details.md) · [Runtime tool index](../runtime.md)

## 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.