Hi @user235 , welcome to the forum!

Tell me a bit more about your use case.

I’m wondering if using a proper webhook could be applicable to you.

Let us know

We present users with an in-app progress tracker for the signing process. If the user is the current signer for a request we’d like to present them with the iframe in a modal and have the modal close when they complete the signing process.

It looks like the only webhook available fires when the entire signing process completes, and not on individual signatures.

Hi @user235,

I did some internal research on this, and it seems it is bing used for the web game only.

Just to confirm how you got here, and restate the problem:

You set a embed_url_external_user_id, and in return you get both the embed_url and the iframeable_embed_url. With these you should be able to either use the Box iframe or create your own.

There is no obvious way to detect when a signer has completed the signature process.

Each signer does have a redirect_url (in case of success) and a declined_redirect_url. I’m wondering if it would be possible to detect the location change in the iframe?

As for webhooks, you are correct, the SIGN_REQUEST.COMPLETED applies to the reuqest not the specific signer.

However we are about to launch a few enhancements to the sign request process. One of the is the SIGN.REQUEST.SIGNATURE_REQUESTED that it is fired when a signer completes its signature.

This has not been officially released yet, but I can already see it in when I try to manually create a webhook:

Obviously not the ideal solution, but you’re welcome to try it out, if it’s applicable to your use case at all.

Let us know if this helps

Hi @rbarbosa ,

Thanks for this, I actually had the same question. I do have a follow up though.

I have a folder called templates where I store box sign request templates that I later retrieve. For a given user, upon them completing something in their profile, a unique sign request is created for this user to sign a document. We create a unique folder for the user, such that once they’ve signed this document, they can see it in their unique folder, not the templates folder.

In the details for Box Sign Weboooks, it states:

There are Box Sign-related events that can trigger the webhooks. Like most of Box events the listeners are set at the folder or document level.





The most common use case is to listen to the events at the folder where the signature requests are created. This way you can listen to all the signature requests created in that folder.

If I have the templates stored in one central folder, but the sign request, once created, is dynamically placed into the given user’s unique folder, is there a way to listen to these docs being signed? Based on the quote above, it seems like I’d have to place the listener webhook on the individual user’s folder, but I don’t think this is possible because these folders won’t have been created yet when I create the webhook. Am I misunderstanding this?

Hi @chriswill21 ,

You are correct yes.

Could you use the parent folder relative to the one that is being created? Or one of the parents in that user structure that makes sense? You can not use the root folder…

Let us know if this helps.

By the way, the new webhooks I was referring to are officially released.

Thanks, @rbarbosa , I’m going to explore both of these options!

Hi @rbarbosa ,

It looks like the new webhooks will be helpful! Unfortunately, it seems they haven’t been released to the box-node-sdk yet (webhooks). Do you know when this might be released for box-node?

Thanks,


Christien

Hi @chriswill21,

I’ll chime in real quick. We recommend migrating to our new generated TS SDK. The new features are delivered much faster so you won’t experience delay in accessing new features like in the Box Node SDK. We just released the stable version of TS SDK and from my understanding it should already support the new webhooks:

Also this migration guide might be useful:

Try it out, you might gradually start using the TS SDK. As always, your feedback is appreciated!

Cheers,


Olga

Thanks, Olga! Looks like those new webhooks aren’t in there yet (pls let me know if I’m mistaken) but I’ll keep an eye out!

Hi @chriswill21 ,

I maybe missing something here, and I’m unfamiliar with the node and typescript SDKs.

I’m not sure what you mean by:

In the python SDK it is a matter of inspecting the webhook payload, that look something like this (simplified):

{


    "type": "webhook_event",


    "id": "4548de33-a405-47af-981b-75f722c2f7ee",


    "created_at": "2024-05-22T08:10:57-07:00",


    "trigger": "SIGN_REQUEST.SIGNATURE_REQUESTED",


    "webhook": {


        "id": "2770072773",


        "type": "webhook"


    },


    "source": {


        "id": "1538251021756",


        "type": "file",


        "name": "Simple-PDF.pdf",


        "item_status": "active"


    },


    "additional_info": {


        "sign_request_id": "ae4b3058-78b8-4526-bb21-d6582ddd383f",


        "signer_emails": i


            "xyz@gmail.com",


            "zxy+signera@gmail.com"


        ],


        "external_id": ""


    }


}

Let us know.

Hi @rbarbosa, Following the developer API reference for Create Webhook, it mentions you must provide trigger parameters that specify what the webhook should be triggered for. When I try the SIGNER_SIGNED trigger (one of the new ones) I get an error. I checked both the node and new typescript githubs to find where the triggers are defined and noticed that they still only have the old triggers defined, which is why I believe I’m getting the error. Apologies if I’m mistaken here.

Hi @chriswill21 ,

Oh, I see what you mean.

As a workaround for the creation process, you can create the webhook manually from the developer console. Not sure if this would fit your use case, for for a test it should be fine.

To do this, access your app from the developer console, flip to the webhooks tab:

These are the details on that webhook, including the new triggers:

Make sure you generate keys to authenticate the webhook payload:

Let us know if this helps.

Thanks, @rbarbosa ! I’ll give this a shot and also keep an eye out for the sdk update.

This topic was automatically closed 4 days after the last reply. New replies are no longer allowed.