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