Currently populate_auto_fill_fields and use_text_tags have identical copy, but are two different features. Update the copy for each to break out the differences between the two so they are no longer identical

I am trying to generate the python SDK of the hellosign with this yaml https://github.com/hellosign/hellosign-openapi/blob/main/openapi-sdk.yaml

The below is the command I am using to generate the SDK

java -jar openapi-generator-cli-6.6.0.jar generate -i D:\openapi-sdk.yaml -g python -o c:\temp\hellosign_python --skip-validate-spec --additional-properties packageName=hellosign.sdk

But the SDK project generated is different from the once they have generated here https://github.com/hellosign/hellosign-openapi/tree/main/sdks/python.

Few API classes are not there. init.py is different with separate clients and so on. How to generate the SDK project same as they have generated?

support for signature request delivery via SMS was added and is currently in beta. However the description for sms_phone_number_type is currently incorrect. This feature delivers a link to complete a signature request. It does not distribute a completed document.

Documentation update:

Calling Update Signature Request and changing the email address of any signer generates a new signature_id value.

Any more attempts to update using the previously-used signature_id will return an error. User must use the new signature_id value returned by this endpoint in any future API calls.

Context: https://faq.hellosign.com/hc/en-us/articles/19742714512013-How-to-test-upcoming-features-with-the-Dropbox-Sign-API

And:

Having authorized by navigating to

"https://app.hellosign.com/oauth/authorize?response_type=code&client_id=${
          process.env.DROPBOX_CLIENT_ID
        }&state=${Date.now()}&redirect_uri=${
          process.env.DROPBOX_REDIRECT_URI
        }"

I then try to get an access token but the request never resolves:

import * as DropboxSign from "@dropbox/sign";

const data = new DropboxSign.OAuthTokenGenerateRequest();

    data.state = query.state;
    data.code = query.code;
    data.clientId = process.env.DROPBOX_CLIENT_ID as string;
    data.clientSecret = process.env.DROPBOX_CLIENT_SECRET as string;
    data.grantType = "authorization_code";

const oAuthApi = new DropboxSign.OAuthApi();
const result = await oAuthApi.oauthTokenGenerate(data);

logger.info(result); <== never gets to this point.

I even tried doing a plain axios request:

const data = {
      state: query.state,
      code: query.code,
      client_id: process.env.DROPBOX_CLIENT_ID as string,
      client_secret: process.env.DROPBOX_CLIENT_SECRET as string,
      grant_type: "authorization_code",
      test_mode: true,
    };

    const result = await axios.request({
      method: "POST",
      url: "https://app.hellosign.com/v3/oauth/token", // <== also tried https://app.hellosign.com/oauth/token
      data,
      headers: {
        "content-type": "application/json",
      },
    });

An ´axios´ POST request will result in a 400 or a 404.

Appreciate your help.

I have a Next.JS application using @dropbox/sign 1.4.1 and I'm trying to send a signature request. This worked before rotating my API key, but now it fails.

Code:

const signatureRequestApi = new DropboxSign.SignatureRequestApi();
signatureRequestApi.username = process.env.HELLO_SIGN_API_KEY || '';
const result = await signatureRequestApi.signatureRequestSendWithTemplate(request);

When I call this, I get the following error:
Internal error: HttpError: HTTP request failed
at eval (./node_modules/@dropbox/sign/dist/api.js:28454:26)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Any suggestions?

I'm trying to integrate the Dropbox Sign Node SDK in my application. I'm building a Next.js application and am using Next 14 with Node 20.8.1. I'm also using Yarn workspaces (for what that's worth). When I try to compile any code that imports from the @dropbox/sign package, I get the following Node module resolution errors:

Failed to compile.

../node_modules/@dropbox/sign/dist/api.js
Module not found: Can't resolve './aes'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./app/admin/dropbox/page.tsx

../node_modules/@dropbox/sign/dist/api.js
Module not found: Can't resolve './blowfish'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./app/admin/dropbox/page.tsx

../node_modules/@dropbox/sign/dist/api.js
Module not found: Can't resolve './cipher-core'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./app/admin/dropbox/page.tsx

../node_modules/@dropbox/sign/dist/api.js
Module not found: Can't resolve './core'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./app/admin/dropbox/page.tsx

../node_modules/@dropbox/sign/dist/api.js
Module not found: Can't resolve './enc-base64'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./app/admin/dropbox/page.tsx

> Build failed because of webpack errors

These all look like relative imports, which may understandably be raising because, for example, the crypto-js package may not expose its modules as siblings of the ../node_modules/@dropbox/sign/dist/api.js file which appears to be executing.

I also don't think I'm the only one experiencing this issue.

Can anyone provide any guidance on this?

Thank you.

For the 'query=null', the response is received. But while specifying the search fields, we are having difficulty in getting response. The signature_request returns the empty response i.e. signatureRequests: []. This maybe because we might be specifying wrong string in query. So it will be great if the query string format is specified in sample code. Note: While hitting the API in the documentation we are receiving the desired response but through code as mentioned earlier returns the empty response.

Wondering if there is an optional field that allows us to specify the name of the requester in order for the name to be displayed in email communications regarding signature requests. Sending Signature Requests through Clio seems to allow for the requester's name to be included in the request as in the 2nd image, but the API documentation for Dropbox Sign doesn't specify a way to obtain this result. Something like the following would be a big help:

Current signature request emails for UnclaimedDraftCreateEmbeddedRequest that only allow requester_email_address:

Desired result:

The node SDK is using crypto-js v4.1.0. On the 25th of October (yesterday) CVE-2023-46233 was published. Fix is on version 4.2.0 of that lib.
I don't know if dropbox/sign is actually vulnerable to that CVE, but it is triggering dependabot alerts on my repos.

I want to try @dropbox/sign in my vue project. When I install @dropbox/sign with npm and import it in my vue component, it has some mistake.
My operation is like this：

1. npm install @dropbox/sign
2. import * as DropboxSign from "@dropbox/sign";

This is the error I encountered：
These relative modules were not found:

• ./aes in ./node_modules/@dropbox/sign/dist/api.js
• ./cipher-core in ./node_modules/@dropbox/sign/dist/api.js
• ./core in ./node_modules/@dropbox/sign/dist/api.js
• ./enc-base64 in ./node_modules/@dropbox/sign/dist/api.js
• ./enc-base64url in ./node_modules/@dropbox/sign/dist/api.js
• ./enc-utf16 in ./node_modules/@dropbox/sign/dist/api.js
• ./evpkdf in ./node_modules/@dropbox/sign/dist/api.js
• ./format-hex in ./node_modules/@dropbox/sign/dist/api.js
• ./hmac in ./node_modules/@dropbox/sign/dist/api.js
• ./lib-typedarrays in ./node_modules/@dropbox/sign/dist/api.js
• ./md5 in ./node_modules/@dropbox/sign/dist/api.js
• ./mode-cfb in ./node_modules/@dropbox/sign/dist/api.js
• ./mode-ctr in ./node_modules/@dropbox/sign/dist/api.js
• ./mode-ctr-gladman in ./node_modules/@dropbox/sign/dist/api.js
• ./mode-ecb in ./node_modules/@dropbox/sign/dist/api.js
• ./mode-ofb in ./node_modules/@dropbox/sign/dist/api.js
• ./pad-ansix923 in ./node_modules/@dropbox/sign/dist/api.js
• ./pad-iso10126 in ./node_modules/@dropbox/sign/dist/api.js
• ./pad-iso97971 in ./node_modules/@dropbox/sign/dist/api.js
• ./pad-nopadding in ./node_modules/@dropbox/sign/dist/api.js
• ./pad-zeropadding in ./node_modules/@dropbox/sign/dist/api.js
• ./pbkdf2 in ./node_modules/@dropbox/sign/dist/api.js
• ./rabbit in ./node_modules/@dropbox/sign/dist/api.js
• ./rabbit-legacy in ./node_modules/@dropbox/sign/dist/api.js
• ./rc4 in ./node_modules/@dropbox/sign/dist/api.js
• ./ripemd160 in ./node_modules/@dropbox/sign/dist/api.js
• ./sha1 in ./node_modules/@dropbox/sign/dist/api.js
• ./sha224 in ./node_modules/@dropbox/sign/dist/api.js
• ./sha256 in ./node_modules/@dropbox/sign/dist/api.js
• ./sha3 in ./node_modules/@dropbox/sign/dist/api.js
• ./sha384 in ./node_modules/@dropbox/sign/dist/api.js
• ./sha512 in ./node_modules/@dropbox/sign/dist/api.js
• ./tripledes in ./node_modules/@dropbox/sign/dist/api.js
• ./x64-core in ./node_modules/@dropbox/sign/dist/api.js

How should I test it locally？Do I need to install some other packages?

The .NET SDK version 1.2.0 added a new field fontSize, which has an int type and a default value of 0.
Code that previously worked now crashes with the error 'font_size' must be between 7 and 49.
I think the type should be int?, not int and the default value is null.

I haven't dug deep, but it looks like this problem exists in other SDKs, such as Java.

By the way, what was the default value in past versions of the SDK so that I could make a quick fix?

hi, when using the exact example (replaced with apikey)

https://github.com/hellosign/hellosign-openapi/blob/main/examples/SignatureRequestGet.cs

we get the following error all the time. any ideas?

Message: 
System.UriFormatException : Invalid URI: The format of the URI could not be determined.

  Stack Trace: 
Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind, UriCreationOptions& creationOptions)
Uri.ctor(String uriString)
RestClientOptions.ctor(String baseUrl)
ApiClient.Exec[T](RestRequest req, RequestOptions options, IReadableConfiguration configuration)
ApiClient.Get[T](String path, RequestOptions options, IReadableConfiguration configuration)
SignatureRequestApi.SignatureRequestGetWithHttpInfo(String signatureRequestId, Int32 operationIndex)
SignatureRequestApi.SignatureRequestGet(String signatureRequestId, Int32 operationIndex)

This description needs to be fixed before this feature comes out of beta

The examples on https://developers.hellosign.com/api/reference/operation/oauthTokenGenerate/ and https://developers.hellosign.com/api/reference/operation/oauthTokenRefresh/ should not use API key as it is not required for these endpoints.

Hi there!

Are there plans to migrate https://github.com/hellosign/hellosign-embedded to the Dropbox'es NPM account?

I'm in the process of moving our app from legacy Hellosign ruby SDK to the new one and there's one missing piece left on the frontend which is hellosign-embedded.

Hello Team,

Do you have any plans for supporting the golang SDK generated from the OpenAPI specs?

I have a fork of the repo and have a draft PR to have it generated. I don't know if this is something which you want to bring in.
abhishekdas29#1

Hi,

just noticed while working on an error regarding the cancellation of signatures, that the error handling in the SDK is missing for certain endpoints, leading to hanging/stuck promises.

https://github.com/hellosign/dropbox-sign-node/blob/723299047cd3785d8793c3234e7f3357e0934312/api/signatureRequestApi.ts#L553-L581

    return interceptorPromise.then(() => {
      return new Promise<returnTypeI>((resolve, reject) => {
        axios.request(localVarRequestOptions).then(
          (response) => {
            let body = response.data;


            if (
              response.status &&
              response.status >= 200 &&
              response.status <= 299
            ) {
              resolve({ response: response, body: body });
            } else {
              reject(new HttpError(response, body, response.status));
            }
          },
          (error: AxiosError) => {
            if (error.response == null) {
              reject(error);
              return;
            }


            const response = error.response;


            let body;
          }
        );
      });
    });

This is just one example, there are multiple cases like this throughout the SDK.

As you can see, the reject is never called, the error handler is basically empty.
I played around a bit and noticed, that this is caused by running prettier. I tried updating prettier to the latest version, but the error persists. Since its autogenerated code, I think disabling it should be a quick fix, but I also saw that you do some post processing afterwards, not sure if that would break when disabling prettier.

When testing callback URL in the UI, a POST request event, with value callback_test, is sent. This will throw an exception, since value is not listed as allowed in EventCallbackRequestEvent schema, thus failing the test for user in the UI.

DropBox::Sign::Configuration adds an extra slash between the host and the base path when calling base_url. This causes all requests sent through the SDK to use a misspelled URL.

For instance:

Dropbox::Sign::EmbeddedApi.new.api_client.config.base_url
=> "https://api.hellosign.com//v3"

I'm in the middle of migrating and noticed this. We override the URL so we can run a mock server for some simple testing and the new SDK wasn't hitting it properly.

At the moment, all examples on the Ruby SDK have variables named "api". Example:
api = HelloSign::SignatureRequestApi.new

We should rename those variables to something more identifiable, such as

signature_request_api = HelloSign::SignatureRequestApi.new

Hello,

We updated spring and as such needed to update the tomcat container we were hosting our application on. We are running into a NoClassDefFoundError.

When calling var apiClient = Configuration.getDefaultApiClient();, we get the following error: java.lang.NoClassDefFoundError: javax/ws/rs/core/Configuration

We've tried multiple things in our pom file including:

1. Adding the javax.ws.rs dependency - this results in the error: java.lang.LinkageError: ClassCastException: attempting to castjar:file:/usr/local/tomcat/webapps/api/WEB-INF/lib/javax.ws.rs-api-2.1.1.jar!/javax/ws/rs/client/ClientBuilder.class to jar:file:/usr/local/tomcat/webapps/api/WEB-INF/lib/javax.ws.rs-api-2.1.1.jar!/javax/ws/rs/client/ClientBuilder.class
2. Setting the javax.ws.rs dependency scope to "provided" - this gives the NoClassDefFoundError
3. Setting the dropbox-sign dependency scope to "compile" - this gives the NoClassDefFoundError

Here might be some relevant information surrounding the container:

`tomcat/lib# java -cp catalina.jar org.apache.catalina.util.ServerInfo
Server version: Apache Tomcat/10.1.6
Server built:   Feb 19 2023 13:23:52 UTC
Server number:  10.1.6.0
OS Name:        Linux
OS Version:     5.4.0-1103-azure
Architecture:   amd64
JVM Version:    17.0.6+10
JVM Vendor:     Eclipse Adoptium

java -version

openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)`

Here was the container we were using before

Here is the updated container

Is there anything we may be missing here?

Does anyone know if HelloSign supports templating and embedded signing for PDF's containing XFA (https://en.wikipedia.org/wiki/XFA)? Example PDF that we would use as a template in HelloSign: https://www.canada.ca/content/dam/ircc/migration/ircc/english/pdf/kits/forms/imm5707e.pdf. Thanks!

Could you please upgrade axios dependency to 1.6.0, following vulnerability found in previous versions?
Snyk's report: https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459
Thanks!

The code sample for templateUpdateFiles:

from pprint import pprint

from dropbox_sign import \
    ApiClient, ApiException, Configuration, apis, models

configuration = Configuration(
    # Configure HTTP basic authorization: api_key
    username="YOUR_API_KEY",

    # or, configure Bearer (JWT) authorization: oauth2
    # access_token="YOUR_ACCESS_TOKEN",
)

with ApiClient(configuration) as api_client:
    template_api = apis.TemplateApi(api_client)

    data = models.TemplateUpdateFilesRequest(
        files=[open("example_signature_request.pdf", "rb")],
    )

    template_id = "5de8179668f2033afac48da1868d0093bf133266"

    try:
        response = template_api.template_update_files(template_id, data)
        pprint(response)
    except ApiException as e:
        print("Exception when calling Dropbox Sign API: %s\n" % e)

... throws error:

HTTP response body: {'error': {'error_msg': 'Could not update template files, file or file_url '
'required.',
'error_name': 'bad_request',
'error_path': 'file'}}

The SDK is not setting the header as multipart/form-data when only the files parameter was being passed. It defaults to application/json thus ignoring the files.

On Node SDK <= v1.4, making an OAuth request uses the default api.hellosign.com/v3 URL, instead of the app.hellosign.com URL:

import * as DropboxSign from "@dropbox/sign";

const api = new DropboxSign.OAuthApi()

api.username = "";

const data: DropboxSign.OAuthTokenGenerateRequest = {
  clientId: "abc123",
  clientSecret: "abc123",
  code: "0ac236ad",
  grantType: "authorization_code",
  state: "0ac236ad",
};

const result = api.oauthTokenGenerate(data);
result.then(response => {
  console.log(response.body);
}).catch(error => {
  console.log("Exception when calling Dropbox Sign API:");
  console.log(error.body);
});

The correct URL should have been set here:

The Legacy SDK Node SDK passed files with a files parameter.
The new, OAS-powered Node SDK passes files with a file parameter.

In order to pass a file path (instead of binary), the new Node SDK requires that you set instantiateFiles to true.

When instantiateFiles is set to false (or not set at all), the following behaviors occur:
Expected: Passing a file path using the file parameter should return an error about incorrect types.
Actual: The error says the parameter is incorrect.

Exception when calling HelloSign API:
_ErrorResponse {
  error: _ErrorResponseError {
    errorMsg: 'Must specify file(s) to be sent.',
    errorName: 'bad_request',
    errorPath: undefined
  }
}

After upgrading to Dropbox.Sign from HelloSign we get the error "The value cannot be null or empty. (Parameter 'mediaType')" when we call SignatureRequestSend.

As far as I can read elsewhere, the error is due to a nullable bug in RestSharp earlier than version 109.0. The error is described here:

restsharp/RestSharp#1969
restsharp/RestSharp#1999

We are using .NET verison 7.0.5 and Dropbox.Sign SDK/Nuget version 1.1.1

Are there any immediate plans to update the dotnet-sdk with a newer version of RestSharp?

Recent change to the RestSharp nuget package causes the following error:

Method not found: 'RestSharp.RestRequest RestSharp.RestRequestExtensions.AddFile(RestSharp.RestRequest, System.String, Byte[], System.String, System.String)'

Steps to replicate:

1. Install nuget Dropbox.Sign(1.4.0)
2. Install newst RestSharp v109.0.0+
3. Use one of the code examples we provide in our repo
4. See exception

The minor change in RestSharp was to the filename parameter in the AddFile() method (filename -> fileName). Possible breaking change because a named argument is being changed.

Hey I am trying to test it for the first time with a Next.js application and got the following

- error ./node_modules/@dropbox/sign/dist/api.js
Module not found: Can't resolve './aes'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./lib/dropbox.ts
./app/page.tsx

The steps I took after initiating my next.js application:

1. npm install @dropbox/sign
2. Try the accountGet() example

          > [dropbox-sign.jar.zip](https://github.com/hellosign/hellosign-openapi/files/13518952/dropbox-sign.jar.zip)

@christiangoudreau here's the compiled package to test it out.

Hey! I looked into this as we also need the Jakarta upgrade jar, and had some mixed results. While the artifacts compiled properly, we had some unexpected failures when attempting to test creating requests with a template locally. I've included below the raw request body sent by the above jar (1), and the message returned by the API (2). I've scrubbed out some of the personal data, but it had more realistic data in there previously.

I'll also include below the raw request body posted by the 1.1.0 jar which is the current version we use (3) which succeeded in creating a Hellosign document request. The difference I see is that the metadata property has an empty default value in the new Jar, where before it was ignored when unset. When I pull our current code and add an empty map to the metadata property, I see the same error. I'll include our current method of calling the endpoint as well for reference (4).

1

{
    "template_ids": [
        "****"
    ],
    "signers": [
        {
            "role": "client",
            "name": "****",
            "email_address": "[email protected]"
        },
        {
            "role": "validator",
            "name": "ECLIPSE EMO-RECORDS",
            "email_address": "[email protected]"
        },
        {
            "role": "signing_authority",
            "name": "****",
            "email_address": "[email protected]"
        }
    ],
    "allow_decline": false,
    "is_qualified_signature": false,
    "is_eid": false,
    "message": "You're signature has been requested for the following document by the Eclipse Foundation. ",
    "metadata": {},
    "subject": "Action Required - Eclipse Foundation Signature Request",
    "test_mode": true,
    "title": "Eclipse Foundation Individual Committer Agreement - TEST"
}

2

com.dropbox.sign.ApiException: class ErrorResponse {
    error: class ErrorResponseError {
        errorMsg: Metadata is malformed
        errorName: bad_request
        errorPath: null
    }
}

3

{
    "template_ids": [
        "****"
    ],
    "signers": [
        {
            "role": "client",
            "name": "****",
            "email_address": "[email protected]"
        },
        {
            "role": "validator",
            "name": "ECLIPSE EMO-RECORDS",
            "email_address": "[email protected]"
        },
        {
            "role": "signing_authority",
            "name": "****",
            "email_address": "[email protected]"
        }
    ],
    "allow_decline": false,
    "is_qualified_signature": false,
    "message": "You're signature has been requested for the following document by the Eclipse Foundation. ",
    "subject": "Action Required - Eclipse Foundation Signature Request",
    "test_mode": true,
    "title": "Eclipse Foundation Individual Committer Agreement - TEST"
}

4
Where template is a custom config object that represents a Hellosign template, request is the request body we consume to generate the request, and signers is a list of processed user objects that was initially included in the request.

            SignatureRequestGetResponse r = signatureRequest
                    .signatureRequestSendWithTemplate(new SignatureRequestSendWithTemplateRequest()
                            .templateIds(List.of(template.templateId()))
                            .title(template.templateName() + (config.testMode() ? " - TEST" : ""))
                            .subject(request.getSubject())
                            .message(request.getMessage())
                            .signers(signers
                                    .stream()
                                    .map(signer -> new SubSignatureRequestTemplateSigner()
                                            .role(signer.getRole())
                                            .emailAddress(signer.getMail())
                                            .name(signer.getName()))
                                    .collect(Collectors.toList()))
                            .testMode(config.testMode()));

Originally posted by @autumnfound in #285 (comment)

Revisit all examples for downloading a file. It doesn't make sense to print_r a stream response

I was trying to switch my app from using hellosign-ruby-sdk to dropbox-sign-ruby and got a crash in Dropbox::Sign::UnclaimedDraftApi#unclaimed_draft_create_embedded when running it with the puma app server:

ETHON: Libcurl initialized
objc[44340]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[44340]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
[44324] - Worker 1 (PID: 44403) booted in 0.0s, phase: 0

My setup is:
Rails - 7.0.4.2
Puma - 6.1.1
Bootsnap - 1.16.0
Spring - not used

When calling getMetadata on a SignatureRequestSendRequest object, it returns a Map<String, Object>. When calling getMetadata on a SignatureRequestResponse, it returns an Object. I have to use reflection to retrieve any metadata properties.

Also, on SignatureRequestSendRequest, there is putMetadataItem, but there is no getMetadataItem.