[jasonbuechler]

I believe it's probably down to firmware - I was on the latest for each, but I'm guessing that going forward it's digest only.  Both firmwares are newer than the API documentation.  
...
That's the python page I landed on as well for implementing digest (we should hang out).  While it seemed straightforward enough for me to re-implement if it was a small monolithic script, the size and interconnectedness of this plugin scared me off.  Too tempting to just swap my $50 amcrest for a $50 foscam and go back to building my better life one bash script at a time.  Though i did consider cheating and dropping to an os.system() in python and just curling the dang things like I know how to do.

haha, drop me a line if you're ever around flagstaff or denver
but yeah I would put my money on the firmware being the culprit. it was certainly a thought when I saw the date of that api revision.

I want you to get this to work as badly as you do, probably. Ever since Foscam's cino-american civil war, I've been planning on moving to Amcrest for my next purchases, but fortunately (or not) these things just refuse to die.  In your position, I would have already folded and cheated with system calls! Props to staying strong.  One thought I had, and I have no idea if it'd work, would be replacing/augmenting urllib with other packages/calls... I'm smelling that both of us are Python hacks at best, but it probably wouldn't be too time-consuming to do some guess-and-check one-off edits to the existing code.

And of course, failing that, maikito mentioned something in his github that when kodi v18 rolls around, he was hoping to remaster the addon... maybe neither of us could get the whole shebang working but maybe if we had some working code/CLI examples, it'd make those additions quick-n-easy for him?
  

Oh, and the curl output - running with -I made it return "empty response" no matter if I fed it basic or digest creds, or what endpoint I hit.  But -vv gave what I think you wanted to see (using netrc to provide user/pass, and below I obscured sensitive info with italics):

curl -vv  -n   "http://CAMERA/cgi-bin/alarm.cgi?action=getOutSlots"
*   Trying CAMERAIP...
* TCP_NODELAY set
* Connected to CAMERA (CAMERAIP) port 80 (#0)
* Server auth using Basic with user 'MYUSER'
> GET /cgi-bin/alarm.cgi?action=getOutSlots HTTP/1.1
> Host: CAMERA
> Authorization: Basic YWRtaW46bGlidGFyZGk1
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Digest realm="Login to FACTORYHOSTNAME",qop="auth",nonce="1484076709",opaque="8b4b92bf58d158222eca1dbf57140fe6c0b92f06"
< Connection: close
< CONTENT-LENGTH: 0
<
* Closing connection 0

If I append --digest to the arguments everything works.  

 
You, sir, just activated a braincell of mine. 'No response at all' struck me as a security measure.  
Which makes sense, given that Basic auth is sent as (reversibly-base64-encoded) plaintext, and therefore you're not supposed to use it over http.
Although the fact upping verbosity yields the information anyway is kinda odd... I'm still curious:
Can you try any of those CGI strings over https, instead??
Might as well see if the headers are any different, as well?