Switching to Rest API from SDK- sessionToken

0 votes

Hello, I'm upgrading an application that user Java SDK to the REST API. 

The application currently does in-person signing of 2 signers in an iFrame.

The design is to now allow the users a choice between in-person or remote signing.

1) as far as supporting in-person, I can't figure out how do I get a session token for the signing ceremonies using the Rest API. Currently doing this:

sessionService = eslClient.getSessionService();
sessionToken = sessionService.createSessionToken(packageId, signer1);

2) If you have any advice on how package creation (json post to /api/packages) would vary for remote versus in-person signing. For example, for in-person, no emails should go out. Anything else that might be helpful. 

I'm thinking that the choice between in-person and remote needs to be made prior to package creation. Is that true?

Thank you, Randy

Reply to: Switching to Rest API from SDK- sessionToken

0 votes

Hi Randy,


Thanks for your post! For your questions:
(1)The SDK function to generate a "session token" was kind of a old fashion to build an an-person signing link. Check the two methods mentioned in this developer blog for the latest practice:


(2)First of all, if you want to suppress outbound email notifications for in-person use cases, you could contact support team ([email protected]) and turn on an account level setting "Disable InPerson Activation Email".

Because in-person transaction, by its nature, allows the signers to both sign remotely or on-site. If you want to handle both scenarios with in-person transaction, you'd invoke an additional API to notify signers when its remote signing scenario. On the contrary, you could also create remote vs in-person transactions to handle both scenarios, as long as you can make the decision prior to package creation.

(3)For your reference, whether a package supports in-person signing determines by a package level settings, see below:

{ "name": "In-Person Signing Transaction", "language": "en", "description": "In-Person Signing Transaction", "status": "DRAFT", "settings": { "ceremony": { "inPerson": true } } }



Duo Liang OneSpan Evangelism and Partner Integrations Developer

Reply to:

0 votes

Thank you. Very helpful. Some follow-ups:

1) our current account is being used for in-person and has Disable InPerson Activation on. So no emails are sent. I don't see anything in our code (old SDK) that indicates inPerson =true. But yet we are doing in-person signing. Unfortunately, our package is created and sent before the point where the user would decide on remote or in-person. Does the "inPerson:True" break remote signing? I guess I'm wondering what that flag actually does, since doesn't control email sending.

2) What is the practical difference between /api/authenticationTokens/signer/multiUse and singleUse ? Does that mean the user can start again if they close their browser for multiUse and not for singleUse?

Thanks, Randy

Reply to:

0 votes

Hi Randy,


For your questions:

(1)I would understand "inPerson:True" as "support in-person signing" rather than "force to launch as in-person signing" - as I mentioned above, in-person transaction supports both remote and on-site signing scenarios. (In-person signing is where you will see a dropdown list with signer names (in old signer experience) or a welcome page with recipient list (in new signer experience), which allows you to switch between signers and complete signing for all signers within one signing ceremony. You can only launch this mode by turning on inPerson:true)

If you don't see anywhere in the code mentioned about in-person, it might be the case that the default package setting has been turned on in-person - this needs to be verified against support team.


(2)You assumption is correct! Once the link built by a signer authentication token has been accessed  - the signer auth token was used to exchange for a session token - a single-use signer auth token will no longer be valid while a multi-use signer auth token still is.



Duo Liang OneSpan Evangelism and Partner Integrations Developer

Hello! Looks like you're enjoying the discussion, but haven't signed up for an account.

When you create an account, we remember exactly what you've read, so you always come right back where you left off