We’re using this feature and it’s doing almost exactly what we need except that the label_url we have to pass in has the requirement that it end in “.pdf”. So far this has prevented us from sending pdfs from most online services because they either clean the link or append authentication information to the end of the link; for instance, shippinglabel.com/label.pdf?api_key=1234. The base object/file is a pdf but to access it externally requires that authentication info.
We also noticed that if we just add “.pdf” to the end of any URL and send it in with the response, it “succeeds” but trying to print the label doesn’t work; like google.com.pdf
Would it possible to accept more than just URLs that end in .pdf?
Can you share with us any orders you experienced this in? I looking for one of the first paragraphs and one of the second. I’d like to bring this up with the team.
I don’t know any orders off the top of my head where this occurred because it was just during our own testing and we had to undo/correct them after the fact anyway. I do have the bodies of the requests sent for each of these scenarios when responding to the Generate Label Webhook, which I’ll add below and try to give context around the failure.
Here is an example of a valid label that is a “.pdf” but has auth info at the end which causes “Print Label” within the shipping.shiphero.com dashboard to fail. Ideally, this response should work as is.
Here is an example where adding “.pdf” to the end of the link caused a “success” when using Print Label. The label link is legit without the .pdf, but Print Label fails unless we add that to the end. And then even though it succeeds, the label isn’t actually printable (because the link is simply invalid).