When a snap is being downloaded and installed and it has a dependency on a base that is not yet installed; what resolves that? Is it the store that knows and tells snapd? Or is it snapd that knows and gets and installs it from the store.
The snap itself clearly knows, it’s in its meta. But it at least doesn’t seem like snapd resolves this independently which kind of surprised me.
But it’s possible I have my wires crossed.
The other thing that happens when a system does not have snapd and it’s installed by apt is it installs snapd the snap.
Or at least based on my flow (Linux Mint 20.1):
result:
$ snap list
Name Version Rev Tracking Publisher Notes
codium 1.56.0 166 latest/stable snapcrafters classic
core18 20210611 2074 latest/stable canonical✓ base
snapd 2.51.1 12398 latest/stable canonical✓ snapd
Whereas I don’t see that same behavior in my other test case.
OK, back to answer my original question myself. 
In /v2/snaps/refresh response for the install action the base needs to properly be set for the snap, in this case codium needed its base set to core18 in that response for snapd to take action.
Now I’m curious what the database does on the backend side, does it parse out the meta and store all of those values in the database? Probably, right?
For snapd to be installed (the snap) by snapd (the debian package) there needs to be a working snapd in the store with all of its “necessary” values returnable by /v2/snaps/refresh. When that’s the case it will be automatically installed.
I hope these notes are helpful for the next person that implements their own snap store. 