I’m looking for information on how to fetch a protected deployment’s previously minted shareable URL create via PATCH /aliases/{id}/protection-bypass.
I’m not seeing/finding an expected GET operation in the API ref and calling the PATCH endpoint a second time results in an error stating the URL has already been created. Clearly the first call’s response can be persisted and reused later; but, the absence of a re-retrieval mechanism seems like a API shortfall, given possible— albeit rare—failures between URL minting and client receipt/processing. Reasonable people will likely agree redeploying to replace a lost link isn’t great API ergonomics.
Clearly there are workarounds. I’m more curious if I’m just missing something obvious. Thanks!
Thank you for bringing this to our attention. I’ll share this with our team and I’m sure there’s a reasoning for it that I’m not aware of currently.
Current Workarounds:
Store the response: The most reliable approach is to persist the shareable link returned from the initial PATCH request in your application’s database or configuration management system.
Revoke and recreate: While not ideal, you can DELETE the existing protection bypass and create a new one: