Skip to main content
Quick Summary: A skill is a company-level definition. Its configuration on a career (benchmark, Required status, per-level activation) belongs to the Career resource, not here.

Attributes

List entries (GET /api/v1/skills) additionally carry a usage object:

Versions and activity

  • GET /api/v1/skills/{id}/versions — every name/description snapshot, who edited it, when, an optional change note, and whether it is the baseline entry written when the skill was created.
  • GET /api/v1/skills/{id}/activity — a version log, not a change feed. Exactly three event types are ever emitted: baseline (skill created), version_created (name or description changed, linked to its version entry via versionId), and renew_training (with affectedUserCount and renewalOption). A request approval, a career adding or removing the skill, and a benchmark or Required-status change produce no entry here — unlike the career activity feed, which records roughly forty event types.

Retirement and delete

Two lanes, both reversible in spirit — prefer archive:
  • POST /api/v1/skills/{id}/archive and POST /api/v1/skills/{id}/unarchive — the retirement path. An archived skill leaves the default library listing but keeps every grade, training and history row, stays readable by id, and can be brought back.
  • DELETE /api/v1/skills/{id} — a soft delete: career attachments, grades and history are preserved as historic data, but the skill leaves every listing, filter and read. When the skill is attached to careers or held by people the call refuses with a 409 conflict carrying dependencies counts; retry with ?confirm=true to proceed. A skill nothing references (a mistyped creation, say) deletes without ceremony.
A deleted skill answers 404 on every read from that point on.