DELETE /api/zsc/:name
Permanently remove the row from zsc_secrets. The ciphertext is
deleted, the IV is deleted, the permissions array is deleted. The
audit entangled state remains intact — every prior secret_read /
secret_set / secret_rotated / secret_denied row in audit_log
stays, hash-linked, as the forensic record that this secret existed.
After deletion, callers of ZeqContext.read(name) get null from
the vault and fall through to process.env[name]. If you want both
the vault and env value gone, unset the env var separately.
Auth
Admin cookie (zeq_admin) required.
Path parameters
| Param | Type | Notes |
|---|---|---|
name | string | The vault key. |
Request
curl -H "Cookie: zeq_admin=$ADMIN_JWT" \
-X DELETE https://YOUR-FRAMEWORK/api/zsc/STRIPE_SECRET_KEY
No body. Irreversible — no soft-delete column, no trash bin. If
you need to recover, re-set the plaintext from your upstream source
of truth.
Response · 200 OK
{ "ok": true, "name": "STRIPE_SECRET_KEY", "deleted": true }
Errors
| Status | error | Cause |
|---|---|---|
400 | name required | Empty path segment. |
401 | unauthorized | Admin cookie missing/invalid. |
404 | NOT_FOUND | No row with this name. |
500 | INTERNAL_ERROR | DB error. |
What's preserved after delete
| Artefact | Survives delete? |
|---|---|
zsc_secrets.value_enc | ❌ Gone |
zsc_secrets.value_iv | ❌ Gone |
zsc_secrets.permissions | ❌ Gone |
audit_log secret_* rows | ✅ All preserved |
proof_digest chain | ✅ Re-verifiable |
prev_hash linkage | ✅ Intact |
The deletion itself is not currently audit-chained as a new
transition type — Phase Ω11 will add secret_deleted for symmetry.
Until then, deletes are visible only as the absence of subsequent
rows after the last secret_set / secret_rotated. Track manually
in your operator log if compliance requires it.
Related
POST /api/zsc/set— restore (with fresh value)POST /api/zsc/revoke— narrower than delete; removes one ZID's access without dropping the secret- Recovery procedures — what to do if you delete the master key