Skip to main content

API Migration guidelines

Upgrading from sms_pin to sms_otp​

Customers should complete this upgrade before 1 September 2022. Support for sms_pin will end on this date.

The new sms_otp authentication supports all the features of sms_pin and more.

Both sms_otp and sms_pin use Scrive's EID Hub service as the authentication provider so the experience for end users doesn't change.

In order to start using sms_otp you should simply replace sms_pin with sms_otp in the process_parameters of your request to start a flow draft.

If you use callbacks, please make sure that your callback handler accepts either sms_pin or sms_otp in the provider field of the payload. This is necessary because callbacks from flows started before the upgrade will contain sms_pin while new callbacks will contain sms_otp.

0.13.5 -> 0.13.6 Preparation for drafts API​

We are working on a replacement for the current Templates API that will provide more flexibility and reusability for our users.

As part of this work we have introduced a new field in the InstanceGetResponse schema called process_parameters. Its structure is identical to the existing field template_parameters so migrating client code is just a search and replace operation.

Also, we have made the template_id in InstanceGetResponse optional, which means it can be null and will eventually be removed. If you use template_id in order to retrieve the process DSL from the template an instance was started from - you can use the newly added process field of the instance itself.

Both template_parameters and template_id will be removed as of 1 September 2021.

0.13.2 -> 0.13.3 Confirmation messages​

Up until now confirmation messages ware sent per document. This is not in line with our vision for this project, so we deprecated the per document confirmation messages.

To allow you to prepare for the change of default behaviour we introduce new confirmation process stage, see DSL spec for more information.

If you would like to opt-in to the new behaviour (unified confirmation messages rather than per-document) prior to this becoming the default, you should include a final confirmation stage as follows:

  - confirmation-stage:
      actions:
        - notify:
            users: [user1]
            kind: confirmation
            methods:
                email: msg1
      expect: {}