Regarding your first question:
EAD XML documents, because they contain the entire descriptive hierarchy and not a single record at a time, tend to be too big to generate and serve on demand via the browser. To avoid this and ensure delivery, there is an option in AtoM to generate XML documents and cache them in advance, so they can be served on demand without needing to be generated first, and thereby generally avoiding the web browser timeout limit. This is described in our documentation here:
You'll find more information on enabling this in the Settings here:
There is also a command-line task that a system administrator can run to pre-generate and cache XML for all existing descriptions. See:
As the documentation notes:
We strongly recommend users enable this setting and run the command-line task if you wish to make EAD 2002 XML available to harvesters via the OAI Repository module. If you do not, then AtoM will return a cannotDisseminateFormat error code to attempts by harvesters to request oai_ead.
Regarding the second:
I'm not actually sure about passing credentials via headers - I would be somewhat concerned about the security of doing so, and recommend you do some testing to see if using the API key might get you what you need. However, I wanted to point out that in most cases, the master digital object will be available at the same URL as that shared in the OAI response, minus the _142 or _141 found at the end of the URL, which specifies the derivatives. The following previous thread has further examples (and exceptions):
You might also find this older post of interest, where I explain how AtoM currently stores digital objects:
As a more long-term alternative:
You could potentially store your images on a separate server or in a DAM of some kind that will provide you with the access you need, rather than uploading them to AtoM directly - so long as your DAM or server can provide you with a valid HTTP/S path that ends in the extension, then when you want to link them to AtoM, you can use the URI option.
However, I'm sure that rethinking how you've been uploading all of your digital objects is not a preferred solution. I will try to see if our developers have any thoughts on getting access to the master object and passing credentials.