Мы столкнулись с этой ошибкой:UNKNOWN_ENVELOPE_RECIPIENT но получатели на самом деле соответствуют
{=> «сообщение» «UNKNOWN_ENVELOPE_RECIPIENT» «ERRORCODE» => "Адресат вы определили не является действительным получателем указанного конверт. Получатель конверта не может быть определен. «clientUserId», «электронная почта» или «имя пользователя» в запросе и конверте могут не совпадать. »}
Однако подписыватели идентифицируются либо по электронной почте, либо по адресу clientUserId (они это и адрес электронной почты), и он совпадает везде. Я проверил четыре раза. Так что эта ошибка кажется просто неправильной. Этот конкретный запрос терпит неудачу только для одного конверта, где я пытаюсь получить встроенный опыт подписи для конкретного пользователя. Я не могу воспроизвести проблему с помощью любых других конвертов, используя разные адреса электронной почты, которые мы создали, чтобы попытаться расследовать эту проблему.
Если пользователь, пытающийся загрузить встроенный опыт подписки, уже имел учетную запись Docusign, это может повлиять на что-нибудь? Из того, что я могу сказать из моего тестирования, эта проблема кажется, что она вытекает из ее электронной почты как-то ... и, похоже, находится на стороне Docusign.
UPDATE:
Я был немного расплывчатым на цели, я не поклонник раскрытия такого рода данных публично. Но, как вы просили, вот возвращается get_recipients:
pry(main)> client.get_envelope_recipients(envelope_id: 'dffa4edc-1fcf-4098-b3e8-9b1a5ed984f8')
=> {
"signers" => [
[0] {
"name" => "Bridget C. Shoemaker",
"email" => "[email protected]",
"recipientId" => "1",
"recipientIdGuid" => "c8edf6a1-ab19-4bd0-af75-715bcec43aa1",
"requireIdLookup" => "false",
"userId" => "1a873cb0-044a-4b3f-9e0d-dc6a948e579b",
"clientUserId" => "[email protected]",
"routingOrder" => "1",
"note" => "",
"roleName" => "Third Party",
"status" => "delivered",
"deliveredDateTime" => "2013-12-09T18:25:44.7800000Z"
}
],
"agents" => [],
"editors" => [],
"intermediaries" => [],
"carbonCopies" => [],
"certifiedDeliveries" => [],
"inPersonSigners" => [],
"recipientCount" => "1",
"currentRoutingOrder" => "1"
}
А вот тело запроса get_recipient_view в формате JSON для REST API
{\"authenticationMethod\":\"email\",\"clientUserId\":\"[email protected]\",\"email\":\"[email protected]\",\"returnUrl\":\"https://app.bolstr.com/accredited_verifications/113/docusign_response?accredited_verification_id=113\",\"userName\":\"Third Party Verification\"}
JSON, который я разместил выше, действительно включает имя пользователя, адрес электронной почты и clientUserId ... Я не уверен, что вы неправильно поняли его? Я также указываю метод аутентификации «email». И, как я уже неоднократно заявлял, это не проблема с нашим кодом. ТОЛЬКО этот конкретный конверт не загружает встроенный URL-адрес подписи. Все остальные предыдущие конверты для этого раздела нашего приложения работали нормально, и я могу создавать новые конверты, которые тоже загружаются. – jondkinney
Извините, что я пропустил «электронную почту» в JSON, которую вы опубликовали. Я обновил свой ответ, чтобы добавить «ОБНОВЛЕНИЕ № 2». –
Видите, это просто ... Я устанавливаю имя как «Проверка третьей стороны» в своем первоначальном запросе на создание конверта, и поэтому я использую то же значение при попытке оттянуть URL-адрес для встроенного подписи. Это восходит к моей первоначальной догадке ... похоже, что Docusign изменил значение имени этого пользователя при создании конверта. Вот почему я спросил, может ли Бриджит иметь учетную запись docusign (я не уверен, действительно ли она на самом деле, но это мое предположение). Опять же, мой код работает нетронутым для тех, у кого нет ее электронной почты. Docusign изменил это имя при создании конверта? – jondkinney