terraform-provider-vercel

What Adds a dedicated * resource granting Vercel REST API permissions (e.g. , , , , ) to a Sign in with Vercel app's tokens — the piece that lets an app act on the platform on the signed-in user's behalf, consented at sign-in. This is the same field the dashboard's Permissions page sets via , so an app can be provisioned end-to-end by Terraform with zero dashboard involvement. Design history: the first revision put on itself, which required a create-then-PATCH-then-delete-on-failure dance (the create endpoint doesn't accept permissions). Review rightly called that hack dangerous; per follow-up discussion, the grant is now its own resource mapping 1:1 onto the PATCH endpoint, and 's Create is a single atomic API call again. Semantics One grant resource per app; it owns the app's whole permission set Create/Update PATCH only ; Delete revokes (PATCHes ) rather than merely forgetting; Read removes itself when the app is gone or has no grants; importable as Clobber-proof by construction: the general deliberately has no permissions field (the API preserves permissions when the field is absent), and sends only* that field — the two resources can't stomp on each other No client-side value enum: the server's evolving permission list is the source of truth Verified against production that setting permissions works with a plain team-owner token Testing Acceptance tests pass against the production API: Unit tests, , , , clean; docs regenerated. Follow-up The deeper fix — the create endpoint accepting directly — remains an change worth making, but nothing here depends on it anymore. Motivation Follow-up to #576: vercel/infra#32272 provisions durabench's Sign in with Vercel app via Terraform, and the API-permission grant was the one remaining dashboard step. With this it's fully declarative: