Skip to content
bento docs

Idempotency

This page is coming soon. Two surfaces, one principle: re-running a mutation never duplicates state.

OSS CLI:

  • bento init — re-running on an already-init’d workspace is a no-op (no clobber, no duplicate bento.toml).
  • bento dish add <path> — re-running on an existing dish updates dish.toml in place; never creates a duplicate.
  • bento mcp install [client] — re-running updates the existing entry in the client’s config rather than appending. The action enum (created / added / updated / unchanged) tells you what happened.
  • bento deploy — uses each integration’s native idempotency primitive (Railway service-id pin, Vercel deployment-id, Cloudflare deployment-id) so a retry resumes rather than double-deploying.

SaaS API (in design): Idempotency-Key header on every state-changing endpoint. Re-submitting the same key returns the original response instead of re-applying the mutation. See OpenAPI for the published surface.