Skip to main content

Box Sign Events API

  • September 27, 2023
  • 5 replies
  • 277 views

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 (admin_logs_streaming).


Similarly, I’m also not able to trigger the SIGNER_DOWNLOADED event - the documentation states that: “A SIGNER_DOWNLOADED 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 SIGNER_DOWNLOADED event?


Could someone please help resolve the discrepancy here?

5 replies

rbarbosa Box
  • Developer Advocate
  • 553 replies
  • September 28, 2023

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.


Cheers


  • Author
  • New Participant
  • 2 replies
  • October 3, 2023

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 .txt and .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!


rbarbosa Box
  • Developer Advocate
  • 553 replies
  • October 3, 2023

Thanks @Vishakan ,


I’ll forward this extra info to the Sign team.


rbarbosa Box
  • Developer Advocate
  • 553 replies
  • October 18, 2023

Hi @Vishakan


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?


Best regards


  • Author
  • New Participant
  • 2 replies
  • October 19, 2023

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!


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings