Hi there, quick followup question RE the newly introduced functionality for flagging order as containing restricted items (in the UK): Flag orders containing restricted items
After we’ve requested a job, how do we detect whether or not the job was flagged as containing restricted items? I don’t see any field in the GET /jobs/xzy response object that would indicate the job was request with (or without) restricted items.
The only field related to age restricted items I can find is deliveries[].proof.signature_url, but presumably this field doesn’t get set until after the delivery has been completed (and while the absence of a value here after a delivery means no signature check was performed, it doesn’t necessarily mean we didn’t flag the order as age-restricted.
I’m asking for two reasons:
Test coverage: we’d like to extend API usage to use the newly introduced restricted items functionality, and would like to extend our test coverage accordingly. As-is I can find no way of extending our tests to confirm we’re correctly flagging restricted items.
Compliance: we’d like to be able to confirm, if needed, that we correctly flagged restricted items for any given order.
I created job 100540291 in the sandbox environment. It contains two dropoffs with delivery IDs 100674706 and 100674705. One should contain restricted items and the other not. Can you confirm which contains the restricted items and what they are?
Thanks @Adrien, can you confirm what the restricted items in delivery 100674706 are, so that I can confirm the restricted item types themselves are correctly getting passed through?
RE exposing the restricted information - I’m surprised to hear you’re unable to add new fields to the GET - Get a Job endpoint without breaking integrations insofar as this was quite recently done with the addition of the proof of delivery URL field.
Maybe the rollout of “proof of delivery URL” unexpectedly broke integrations, or perhaps said rollout required a lot of painstaking coordination? It’s also fine if “exposing restricted information” is just low on the priority queue