UsersApi::getContactById/getContactByIdWithHttpInfo doesn't allow to specify GET-parameters to HTTP request, to receive more than 1st page

[utilmind]

Hello!

Unfortunately Docusign UserApi from SDK returns only first page of contacts (maximum 20 contacts per request), when I retrieving the LIST of contacts (without specifying the {contactId} parameter).

Typical response to getContactById() method of UsersApi is the array with following values:

contacts - Array of contacts
endPosition - 19
nextUri - /accounts/{MY-ACCOUNT-ID}/contacts?keyword=&shared=true&startPosition=20&count=20
resultSetSize - 20
startPosition - 0
totalSetSize - 103

I wish I could add "startPosition" and "count" parameters to request. Without additional GET-parameters I'm doomed to receive only the first page with SDK :( I don't want to use completely customized solution, since in general I'm satisfied by SDK, so I'm going to modify https://github.com/docusign/docusign-esign-php-client/blob/master/src/Api/UsersApi.php, to allow adding GET-parameters to HTTP request, then I will submit pull request.

P.S. ResourcePath for HTTP request looks like follows: /v2.1/accounts/{accountId}/contacts/{contactId}. I'm tried to specify my custom GET-parameters instead of ContactId, but unfortunately this doesn't work, since {contactId} value getting urlEncoded, so parameters like ?startPosition=20 being converted to %3FstartPosition%3D20 and request failing due to bad syntax.

[SayedHusseinElsayed]

the below Get method is working with parameter startPosition {{baseUrl}}/v2.1/accounts/{{accountId}}/contacts?startPosition=10

[utilmind]

the below Get method is working with parameter startPosition {{baseUrl}}/v2.1/accounts/{{accountId}}/contacts?startPosition=10

Of course. But unfortunately there is no way to specify startPosition parameter (and any GET-parameter at all) using getContactById() method from PHP SDK.

[SayedHusseinElsayed]

you can have a look to the below blog post https://www.docusign.com/blog/developers/v2-userslist-paging-change

[LarryKlugerDS]

I believe you set query parameters via the SDK method's options argument.

See https://github.com/docusign/docusign-esign-php-client/blob/beefddccf32a9c58ab96428fa203a67fa0843c7e/src/Api/UsersApi.php#L1977

[utilmind]

I believe you set query parameters via the SDK method's options argument.

See

https://github.com/docusign/docusign-esign-php-client/blob/beefddccf32a9c58ab96428fa203a67fa0843c7e/src/Api/UsersApi.php#L1977

No, the $options have no effect to custom HTTP-parameters. It's only can be used to set up "cloud_provider" parameter, but anything else.

Here is the original PHP code:

    public function getContactByIdWithHttpInfo($account_id, $contact_id, \DocuSign\eSign\Api\UsersApi\GetContactByIdOptions $options = null): array
    {
        // ... SKIPPED
        $queryParams = $headerParams = $formParams = [];
        // ... SKIPPED

        if ($options != null)
        {
            // query params
            if ($options->getCloudProvider() != 'null') {
                $queryParams['cloud_provider'] = $this->apiClient->getSerializer()->toQueryValue($options->getCloudProvider());
            }
        }

        // ... SKIPPED

        // make the API Call
        try {
            list($response, $statusCode, $httpHeader) = $this->apiClient->callApi(
                $resourcePath,
                'GET',
                $queryParams,
                $httpBody,
                $headerParams,
                '\DocuSign\eSign\Model\ContactGetResponse',
                '/v2.1/accounts/{accountId}/contacts/{contactId}'
            );

My solution added $queryParams, but it still have backward compatibility. If $queryParams has "object" type it considered as $options.

    public function getContactByIdWithHttpInfo($account_id, $contact_id, $queryParams = [], \DocuSign\eSign\Api\UsersApi\GetContactByIdOptions $options = null): array
    {
        // ... SKIPPED

        if ($options === null) {
            if ('object' === gettype($queryParams)) { // if $queryParams is 'object', consider it as $options, for backward compatibility.
                $options = $queryParams;
                $queryParams = [];
            }

        }elseif ($options->getCloudProvider() !== 'null') {
            if (empty($queryParams)) $queryParams = [];
            $queryParams['cloud_provider'] = $this->apiClient->getSerializer()->toQueryValue($options->getCloudProvider());
        }

        // ... SKIPPED

        // make the API Call
        try {
            list($response, $statusCode, $httpHeader) = $this->apiClient->callApi(
                $resourcePath,
                'GET',
                $queryParams,
                '', // $httpBody,
                $headerParams,
                '\DocuSign\eSign\Model\ContactGetResponse',
                '/v2.1/accounts/{accountId}/contacts/{contactId}'
            );

[utilmind]

the below Get method is working with parameter startPosition {{baseUrl}}/v2.1/accounts/{{accountId}}/contacts?startPosition=10

[utilmind]

you can have a look to the below blog post https://www.docusign.com/blog/developers/v2-userslist-paging-change

It's quite possible that code described in that blog post works with NodeJS, but certainly not with PHP SDK. Unfortunately with original PHP SDK you don't have any possibility to specify custom parameters to your query. I demonstrated it in the code snippets above.

Anyway, my solution already works for me, I'm successfully receiving the full list of contacts, page by page. Hopefully my fix will become canonical and pull request will be approved. Thanks!

[LarryKlugerDS]

Thanks for checking the options idea. I will alert the SDK product manager to this issue. /Larry

[jglassenberg]

Hi everyone, this ticket is still under investigation by the engineers on our team. I can't provide details just yet but this is a priority item for us to review.

[utilmind]

No problem. And BTW I can submit some more fixes for DocuSign SDK for PHP. It's not critical, I already fixed it for my project, but this could be useful for new users.

[jglassenberg]

If you have other fixes, much appreciated. We can review those issues and fixes as we continue to improve our SDKs.

[jglassenberg]

A belated update: this issue was fixed and released in December before the holidays. If anyone here has still encountered this issue, please let us know.