I’m utilising the Box Sign Events API to construct my workflows.
The API provides capacity to monitor the sign document when it is converted to a
.pdf file, using the
SIGN_DOCUMENT_CONVERTED event. However, this event does not seem to trigger - I’ve tried using different sign document file formats. They all get successfully converted to a PDF for signing, but the
CONVERTED event never seems to show up in the enterprise events stream (
Similarly, I’m also not able to trigger the
SIGNER_DOWNLOADED event - the documentation states that: “A
event_type is produced when a signer downloads the signing document.”, but when I test this out, I only receive an additional
SIGN_DOCUMENT_VIEWED_BY_SIGNER event (note that this isn’t the event upon opening the sign document email, but an additional one when I click the download button in the Box sign UI). Is this an intentional behaviour? If so, how do we trigger the
Could someone please help resolve the discrepancy here?
Hi @Vishakan , welcome to the forum.
This is interesting, does this only happen when you monitor the admin logs?
What I mean is, if you create a webhook on those files/folder/events, do they get triggered?
I’m going to forward this query to our sign team, but it would be helpful if you add some more context and steps to reproduce this.
Hey, @rbarbosa - yep, I’m able to consistently observe this in
admin_logs_streaming (near real-time stream). Just FYI - I have not tried using
admin_logs (the historical events querying stream)
With regards to webhook setup, yes - I have tried using webhooks 2.0 on the same file/folder to monitor for events and they do work - I am able to receive supported signer related webhook notifications as well. I don’t observe any anomaly here.
I believe the steps to reproduce are fairly straightforward here - I created a sign document, assigned a user to sign it, then opened the document as the user to sign it from another private browser window & downloaded it. Following this, I made an API call to the
/events endpoint with
admin_logs_streaming as the stream type (according to the docs, this particular stream should have a record of all recent events, correct me if I’m wrong). I only observe a
SIGN_DOCUMENT_VIEWED_BY_SIGNER event twice (one for opening the document, and the other which was supposed to be a download event).
I’m unable to trigger the
SIGN_DOCUMENT_CONVERTED event at all - I’ve tried creating sign documents out of different file types (like
.docx). They do get converted into a PDF for the signing process, but I’m not observing this event in the API response. Is this the expected way in which this event is supposed to be triggered? Relevant Box API docs suggest this, but there’s some discrepancy.
Also, there aren’t equivalent events under the webhook 2.0 (i.e. sign request downloaded/converted), but the other event types do trigger with webhooks & the
/events stream on the same folder.
Thanks for your time!
Thanks @Vishakan ,
I’ll forward this extra info to the Sign team.
Sorry for the late reply on my part.
The engineering team is telling me that they do not fire the
SIGN_DOCUMENT_CONVERTED, so it seems we have an inconsistency in our documentation.
Is this particular event critical for your use case?
No, that’s okay @rbarbosa - thanks for the update.
I just wanted to be sure it wasn’t something to do on our end.
Please do let me know if it gets supported in the future!