Having problems integrating?¶
Remember that if you are having problems creating a job in a portal signature flow, you can always get in touch with a human on Github:
You may identify the signature job’s signers by personal identification number
IdentifiedByPersonalIdentificationNumber or contact information. When identifying by contact information, you may choose between instantiating a
IdentifiedByEmail, :code:`IdentifiedByMobileNumber or
You can specify a signature type and required authentication level. If signature type or required authentication level is omitted, default values as specified by the functional documentation will apply:
Note that only public organizations can do
Get status changes¶
All changes to signature jobs will be added to a queue. You can poll for these changes. All changes must be confirmed after saving or handling them in your system. The following example shows how this can be handled and examples of data to extract from a change response.
If you retrieve a status change, it will be temporarily removed from the queue. If not confirmed it will reappear after some time.
Get signed documents¶
When getting XAdES and PAdES for a PortalJob, remember that the XAdES is per signer, while there is only one PAdES.
Specifies the queue that jobs and status changes for a signature job will occur in for signature jobs where
StatusRetrievalMethod == POLLING. This is a feature aimed at organizations where it makes sense to retrieve status changes from several queues. This may be if the organization has more than one division, and each division has an application that create signature jobs through the API and want to retrieve status changes independent of the other division’s actions.
To specify a queue, set
pollingQueue through when constructing a sender. Please note that the same sender must be specified when polling to retrieve status changes. The
Sender can be set globally in
ClientConfiguration or on every job.
After receiving a status change, the documents can be deleted as follows: