Hi again Boon,
We asked you to explain your use case in detail, to see if we could come up with an idea about how to implement it using today’s features on our platform. That’s our Support team’s primary goal: enable your success with our product. When you bring a solution like “I want terraform to manage X”, we can’t do that as well. However, after reading your details - with or without terraform, today, we don’t store data about git tags, nor can we do anything useful with commit refs unless you have successfully (or tried unsuccessfully) deployed from that ref as notified by your git provider - in which case you can find and activate or rollback that deploy via our API (albeit slowly, since there is not a query by sha, but a loop over all deploys).
Can you still reason about or be sure about what’s deployed using what we have already? I think so. You use locked deploys and only promote to production commits that you trust; you can see the commit it came from when you are doing automated operations.
We aren’t experts in automation and so can’t speak to the available tools outside our platform, so our experience and advice comes through that filter.
But it is my read that you want to control which deploys are made using our API without having git notify us about each commit, and to do that you will in fact have to do one of these things:
we could ourselves write a new terraform module that would wrap the full-featured Netlify apis to do just this for us! That being said, we’re not a devops shop and we’ve got a long laundry list of “to dos” for our own application that mean that we’re not going to tackle this kind of project in the foreseeable future.
or
if we can’t find something out there that fits into our workflow, we’ll do one of two things: create some CI automation to do netlify deployments or start using some designated branches (e.g. having a branch for “pre-production” and one for “staging” etc)
I think that “create some CI automation to do Netlify deployments” may actually be the best path, since then you know exactly what is being deployed before you send it. You don’t have to use our build system; you don’t even have to deploy from it (you could build, save to git, do QA on the output, then manually deploy once QA is complete, using those files and no build command).
Regardless, I hope you don’t think you wasted your time in describing your use case; it is indeed not something our system enables in the way you want, after several fairly smart product experts thought about it 
PS: Mind being a bit kinder to us in your responses? You come across as really angry and insulting some of the time and it’s pretty offputting; we’re humans and we are trying to help.