Can't remove email address from EWS contact - ews-javascript-api

I'm using the ews-javascript-api to manage my EWS contacts on an exchange server.
I'm trying to update a contact object by removing an email address.
I've followed this blog post and it's got me most of the way there. However, when I remove the ExtendedProperty's for EmailAddress1 the ews-javascript-api throws an exception due to an HTTP 500 coming back from the EWS soap request to update a contact. Looking at the SOAP request, I can see that there is an empty FieldURI which is what the response error is complaining about.
Here is my soap request
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<soap:Header>
<t:RequestServerVersion Version="Exchange2010_SP2"></t:RequestServerVersion>
</soap:Header>
<soap:Body>
<m:UpdateItem MessageDisposition="SaveOnly" ConflictResolution="AutoResolve">
<m:ItemChanges>
<t:ItemChange>
<t:ItemId Id="AAMkADczNzM2MTM4LTZmNWItNDBhYy05ZjcwLWUxMDc3ZDY2NjFiMABGAAAAAAC3bTmWRbrTRqYt+VZXGp68BwD5r6sZ7j5YSprMfvM2gaMkAAAAAAAQAAD5r6sZ7j5YSprMfvM2gaMkAAB4CjURAAA=" ChangeKey="EQAAABYAAAD5r6sZ7j5YSprMfvM2gaMkAAB4CkS4"></t:ItemId>
<t:Updates>
<t:SetItemField>
<t:FieldURI FieldURI="contacts:DisplayName"></t:FieldURI>
<t:Contact>
<t:DisplayName>Craig </t:DisplayName>
</t:Contact>
</t:SetItemField>
<t:SetItemField>
<t:FieldURI FieldURI="contacts:GivenName"></t:FieldURI>
<t:Contact>
<t:GivenName>Craig</t:GivenName>
</t:Contact>
</t:SetItemField>
<t:DeleteItemField>
<t:FieldURI></t:FieldURI>
</t:DeleteItemField>
<t:DeleteItemField>
<t:FieldURI FieldURI="contacts:MiddleName"></t:FieldURI>
</t:DeleteItemField>
<t:DeleteItemField>
<t:FieldURI FieldURI="contacts:Surname"></t:FieldURI>
</t:DeleteItemField>
</t:Updates>
</t:ItemChange>
</m:ItemChanges>
</m:UpdateItem>
</soap:Body>
And here is the soap response
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<s:Fault>
<faultcode
xmlns:a="http://schemas.microsoft.com/exchange/services/2006/types">a:ErrorSchemaValidation
</faultcode>
<faultstring xml:lang="en-US">The request failed schema validation: The required attribute 'FieldURI' is missing.</faultstring>
<detail>
<e:ResponseCode
xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">ErrorSchemaValidation
</e:ResponseCode>
<e:Message
xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">The request failed schema validation.
</e:Message>
<t:MessageXml
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<t:LineNumber>1</t:LineNumber>
<t:LinePosition>1037</t:LinePosition>
<t:Violation>The required attribute 'FieldURI' is missing.</t:Violation>
</t:MessageXml>
</detail>
</s:Fault>
</s:Body>
And finally here is the exception that the javascript api throws.
"Exception
at UpdateItemRequest../node_modules/ews-javascript-api/js/Core/Requests/ServiceRequestBase.js.ServiceRequestBase.ProcessWebException (https://sr1.genband.com/genlync/bundle-electron.js:44707:36)
at https://sr1.genband.com/genlync/bundle-electron.js:45557:41
at <anonymous>"
Finally I'll mention that I can remove an email address without removing any extended properties with the following function.
response.EmailAddresses._setItem(ews.EmailAddressKey.EmailAddress1, address.value);
However, the problem with this is, while it looks like it works, if I try to edit that contact on my outlook web interface, I get an error about some property mismatch. Looks like if I don't remove those extended properties when deleting an email, then they stay around and cause issues for other clients.

this should work in 0.9.3 version, available starting 0.9.3-dev.1 which is ews-javascript-api#next currently.

Related

Node + Soap call works within app, but fails when request is run from Postman

I'm using node and the soap package. The code works and fetches the account info I need. This is legacy code which I'm trying to reverse engineer. When I call the soap packages' client.lastRequest, console.log('last request: ', client.lastRequest) I see the SOAP call that was made:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract"
xmlns:tns="https://bingads.microsoft.com/Customer/v13"
xmlns:q1="https://adapi.microsoft.com"
xmlns:q2="https://adapi.microsoft.com"
xmlns:q3="https://adapi.microsoft.com"
xmlns:q4="https://adapi.microsoft.com"
xmlns:q5="https://adapi.microsoft.com"
xmlns:q6="https://adapi.microsoft.com"
xmlns:q7="https://adapi.microsoft.com"
xmlns:q8="https://adapi.microsoft.com"
xmlns:q9="https://adapi.microsoft.com"
xmlns:q10="https://adapi.microsoft.com"
xmlns:q11="https://adapi.microsoft.com"
xmlns:q12="https://adapi.microsoft.com"
xmlns:q13="https://adapi.microsoft.com"
xmlns:q14="https://adapi.microsoft.com"
xmlns:q15="https://adapi.microsoft.com"
xmlns:q16="https://adapi.microsoft.com"
xmlns:q17="https://adapi.microsoft.com"
xmlns:q18="https://adapi.microsoft.com"
xmlns:q19="https://adapi.microsoft.com"
xmlns:q20="https://adapi.microsoft.com"
xmlns:q21="https://adapi.microsoft.com"
xmlns:q22="https://adapi.microsoft.com"
xmlns:q23="https://adapi.microsoft.com"
xmlns:q24="https://adapi.microsoft.com"
xmlns:q25="https://adapi.microsoft.com"
xmlns:q26="https://adapi.microsoft.com"
xmlns:q27="https://adapi.microsoft.com"
xmlns:q28="https://adapi.microsoft.com"
xmlns:q29="https://adapi.microsoft.com"
xmlns:q30="https://adapi.microsoft.com"
xmlns:q31="https://adapi.microsoft.com"
xmlns:q32="https://adapi.microsoft.com"
xmlns:q33="https://adapi.microsoft.com"
xmlns:q34="https://adapi.microsoft.com"
xmlns:q35="https://adapi.microsoft.com"
xmlns:q36="https://adapi.microsoft.com"
xmlns:q37="https://adapi.microsoft.com">
<soap:Header>
<tns:Action>GetAccountsInfo</tns:Action>
<tns:ApplicationToken>actual_token</tns:ApplicationToken>
<tns:AuthenticationToken>actual_token</tns:AuthenticationToken>
<tns:DeveloperToken>actual_token</tns:DeveloperToken>
</soap:Header>
<soap:Body>
<GetAccountsInfoRequest
xmlns="https://bingads.microsoft.com/Customer/v13" xsi:nil="true">
</GetAccountsInfoRequest>
</soap:Body>
</soap:Envelope>
I also output the URL:
https://clientcenter.api.bingads.microsoft.com/Api/CustomerManagement/V13/CustomerManagementService.svc?wsdl
When I copy these into Postman/Insomia/other API clients I get a 200 OK response BUT not the data I need. The returned XML is 1000s of lines of what looks like the API (Microsoft/Bing Ads API for their customer management service) definition.
I assume it's telling me that the request is wrong, so here, take a guide. But I don't know where to begin looking.
Anything I should look out for when translating Nodes' soap package -> a SOAP call within Postman?

Is there a way to add Custom Document Fields to an envelope document using the DocuSign SOAP API?

I attempted to use CreateEnvelopeFromTemplates SOAP message and included DocumentFields:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:CreateEnvelopeFromTemplates xmlns:ns1="http://www.docusign.net/API/3.0">
<ns1:TemplateReferences>
<ns1:TemplateReference>
<ns1:TemplateLocation>Server</ns1:TemplateLocation>
<ns1:Template>BD944A97-BF86-4FA8-9BAF-EBEECD9BDCAC</ns1:Template>
<ns1:Document>
<ns1:ID>1</ns1:ID>
<ns1:Name>Test Doc</ns1:Name>
<ns1:PDFBytes>JVB...</ns1:PDFBytes>
<ns1:DocumentFields>
<ns1:DocumentField>
<ns1:Name>DOC_CUSTOM_FLD_NAME</ns1:Name>
<ns1:Value>Doc Custom Field Value</ns1:Value>
</ns1:DocumentField>
</ns1:DocumentFields>
</ns1:Document>
<ns1:RoleAssignments>
<ns1:RoleAssignment>
<ns1:RoleName>Applicant</ns1:RoleName>
<ns1:RecipientID>1</ns1:RecipientID>
</ns1:RoleAssignment>
</ns1:RoleAssignments>
</ns1:TemplateReference>
</ns1:TemplateReferences>
But the DocumentFields were not returned on the CreateEnvelopeFromTemplatesResponse and are not returned when making a RequestStatusWithDocumentFields SOAP call:
<soap:Body>
<RequestStatusWithDocumentFieldsResponse xmlns="http://www.docusign.net/API/3.0">
<RequestStatusWithDocumentFieldsResult>
...
<DocumentStatuses>
<DocumentStatus>
<ID>1</ID>
<Name>Test Doc</Name>
<TemplateName>External Doc Test Template</TemplateName>
<Sequence>1</Sequence>
</DocumentStatus>
</DocumentStatuses>
</RequestStatusWithDocumentFieldsResult>
</RequestStatusWithDocumentFieldsResponse>
</soap:Body>
Should CreateEnvelopeFromTemplates support DocumentFields if included?
Is the SOAP API still maintained by DocuSign?
I also looked, but was unable to find anything in the SOAP API like the "Add Custom Document Fields to an Envelope Document" found in the REST API:
URL:
/accounts/{accountId}/envelopes/{envelopeId}/documents/{documentId}/fields
I know I may have to use REST API calls to accomplish this, but would appreciate any help understanding if SOAP API can do this before I go down that path.

Netsuite No Web Services Permission

I'm currently fighting with Netsuite's API and for the past while was getting somewhere, until quite randomly my user was no longer able to log in at all (WebFault: Server raised fault: 'You do not have permission to access web services feature.'). Is there a hidden max API calls/hour that I've hit? I've gone through and checked all 3 relevant places for web services (Company, role, and user is in role). Can anyone shed some light on this (quite frankly nightmare of an) api?
DEBUG:suds.client:sending to (https://webservices.netsuite.com/services/NetSuitePort_2014_1)
message:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:ns0="urn:core_2014_1.platform.webservices.netsuite.com" xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns2="urn:messages_2014_1.platform.webservices.netsuite.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<ns1:Body>
<ns2:login>
<ns2:passport>
<ns0:email>*********</ns0:email>
<ns0:password>*******</ns0:password>
<ns0:account>********</ns0:account>
<ns0:role>******</ns0:role>
</ns2:passport>
</ns2:login>
</ns1:Body>
</SOAP-ENV:Envelope>
DEBUG:suds.client:headers = {'SOAPAction': u'"login"', 'Content-Type': 'text/xml; charset=utf-8'}
ERROR:suds.client:<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:ns0="urn:core_2014_1.platform.webservices.netsuite.com" xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns2="urn:messages_2014_1.platform.webservices.netsuite.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<ns1:Body>
<ns2:login>
<ns2:passport>
<ns0:email>***************</ns0:email>
<ns0:password>*********</ns0:password>
<ns0:account>********</ns0:account>
<ns0:role>*********</ns0:role>
</ns2:passport>
</ns2:login>
</ns1:Body>
</SOAP-ENV:Envelope>
DEBUG:suds.client:http failed:
<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><soapenv:Fault><faultcode>soapenv:Server.userException</faultcode><faultstring>You do not have permission to access web services feature.</faultstring><detail><platformFaults:insufficientPermissionFault xmlns:platformFaults="urn:faults_2014_1.platform.webservices.netsuite.com"><platformFaults:code>WS_PERMISSION_REQD</platformFaults:code><platformFaults:message>You do not have permission to access web services feature.</platformFaults:message></platformFaults:insufficientPermissionFault><ns1:hostname xmlns:ns1="http://xml.apache.org/axis/">partners-java026.svale.netledger.com</ns1:hostname></detail></soapenv:Fault></soapenv:Body></soapenv:Envelope>
I was successfully logging in and out, as well as accessing the getServerTime() method when it blew up on me, and I haven't been able to log in since.
Thanks in advance.
Check-list:
Under Roles
1) Web Services Only Role checked
2) Check that they have the web services permission
Employee
1) check that they have the role and the password is correct
2) Concurrent Web Services User is checked
RE: You Max Calls per Hour Question.
No that is not the case. A Normal Netsuite User is allowed to process 1 API request at any one time, if a second is submitted while the first is still processing it will be rejected with an exception.
You can upgrade your user to a 'Suite Plus' License to achieve 10 concurrent requests for many £££££
Take a look at the user's Role. Go to the Permissions>Setup and make sure Web Services is listed. If not, add it and save.

INVALID_LOGIN_CREDENTIALS error on NetSuite, but correct credentials

I've been trying to use the NetSuite api for sometime using the netsuite gem.
I can login to the website, but when I try to authenticate from the API I get an INVALID_LOGIN_CREDENTIALS error.
This is the payload of the request:
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:platformMsgs="urn:messages_2011_1.platform.webservices.netsuite.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:platformCore="urn:core_2011_1.platform.webservices.netsuite.com">
<env:Header>
<platformMsgs:passport>
<platformCore:email>email#email.com</platformCore:email>
<platformCore:password>--snip--</platformCore:password>
<platformCore:account>ACCOUNTNO</platformCore:account>
<platformCore:role type="role" internalId="ROLE"/>
</platformMsgs:passport>
</env:Header>
<env:Body>
<platformMsgs:get>
<platformMsgs:baseRef xsi:type="platformCore:RecordRef" internalId="4" type="customer"/>
</platformMsgs:get>
</env:Body>
</env:Envelope>
This is the payload of the response:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server.userException</faultcode>
<faultstring>You have entered an invalid email address or account number. Please try again.</faultstring>
<detail>
<platformFaults:invalidCredentialsFault xmlns:platformFaults="urn:faults_2011_1.platform.webservices.netsuite.com">
<platformFaults:code>INVALID_LOGIN_CREDENTIALS</platformFaults:code>
<platformFaults:message>You have entered an invalid email address or account number. Please try again.</platformFaults:message>
</platformFaults:invalidCredentialsFault>
<ns1:hostname xmlns:ns1="http://xml.apache.org/axis/">sb-partners-java002.svale.netledger.com</ns1:hostname>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
I've just solved the issue. If you're having trouble make sure that:
You are connecting to the right environment. (non-sandbox vs sandbox)
Your user (or your role) have WebServices permission (see in Permissions > Setup)
I faced both of the issues. My account, even belonging to an Administrator role, lacked Web Services permission. And I was using the sandbox url to a non-sandbox account.
https://webservices.na1.netsuite.com/wsdl/v2012_1_0/netsuite.wsdl (non-sandbox)
https://webservices.sandbox.netsuite.com/wsdl/v2012_1_0/netsuite.wsdl (sandbox)
Another possible cause of this issue is if the password contains + or % characters. Removing these from the password fixed this for me.

Invalid XML feed from DocuSign Connect

When using Connect to receive a docusign envelope via a web service we have received invalid XML for one of our envelopes. Personal data and PDFBytes have been removed from this copy.
<?xml version="1.0" encoding="utf-8"?><DocuSignEnvelopeInformation xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.docusign.net/API/3.0"><EnvelopeStatus><RecipientStatuses><RecipientStatus><Type>Signer</Type><Email>#ymail.com</Email><UserName>o</UserName><RoutingOrder>1</RoutingOrder><Sent>2013-07-03T13:36:59.257</Sent><Delivered>2013-07-04T09:35:13.23</Delivered><Signed>2013-07-04T10:01:21.447</Signed><DeclineReason xsi:nil="true" /><Status>Completed</Status><RecipientIPAddress>_</RecipientIPAddress><CustomFields /><TabStatuses><TabStatus><TabType>Custom</TabType><Status>Signed</Status><XPosition>927</XPosition><YPosition>1162</YPosition><TabLabel>SSN</TabLabel><TabName>SSN</TabName><TabValue>_</TabValue><DocumentID>1</DocumentID><PageNumber>1</PageNumber><ValidationPattern /><CustomTabType>SSN</CustomTabType></TabStatus><TabStatus><TabType>FirstName</TabType><Status>Signed</Status><XPosition>100</XPosition><YPosition>1166</YPosition><TabLabel>First Name</TabLabel><TabName>First Name</TabName><TabValue>_</TabValue><DocumentID>1</DocumentID><PageNumber>1</PageNumber></TabStatus><TabStatus><TabType>LastName</TabType><Status>Signed</Status><XPosition>462</XPosition><YPosition>1166</YPosition><TabLabel>Last Name</TabLabel><TabName>Last Name</TabName><TabValue>_</TabValue><DocumentID>1</DocumentID><PageNumber>1</PageNumber></TabStatus><TabStatus><TabType>Custom</TabType><Status>Signed</Status><XPosition>1072</XPosition><YPosition>1291</YPosition><TabLabel>Data Field 5</TabLabel><TabName>Text</TabName><TabValue>1</TabValue><DocumentID>1</DocumentID><PageNumber>1</PageNumber><ValidationPattern /><CustomTabType>Text</CustomTabType></TabStatus><TabStatus><TabType>Custom</TabType><Status>Signed</Status><XPosition>664</XPosition><YPosition>1193</YPosition><TabLabel>Exemptions</TabLabel><TabName>Single</TabName><TabValue>X</TabValue><DocumentID>1</DocumentID><PageNumber>1</PageNumber><ValidationPattern /><CustomTabType>Radio</CustomTabType></TabStatus><TabStatus><TabType>SignHere</TabType><Status>Signed</Status><XPosition>406</XPosition><YPosition>1420</YPosition><TabLabel>Signature 9</TabLabel><TabName>Sign Here</TabName><TabValue /><DocumentID>1</DocumentID><PageNumber>1</PageNumber></TabStatus><TabStatus><TabType>Custom</TabType><Status>Active</Status><XPosition>756</XPosition><YPosition>1193</YPosition><TabLabel>Exemptions</TabLabel><TabName>Married</TabName><TabValue /><DocumentID>1</DocumentID><PageNumber>1</PageNumber><ValidationPattern /><CustomTabType>Radio</CustomTabType></TabStatus><TabStatus><TabType>Custom</TabType><Status>Active</Status><XPosition>845</XPosition><YPosition>1193</YPosition><TabLabel>Exemptions</TabLabel><TabName>Married but Single</TabName><TabValue /><DocumentID>1</DocumentID><PageNumber>1</PageNumber><ValidationPattern /><CustomTabType>Radio</CustomTabType></TabStatus><TabStatus><TabType>Custom</TabType><Status>Active</Status><XPosition>100</XPosition><YPosition>1208</YPosition><TabLabel>Address</TabLabel><TabName>Address Line 1</TabName><TabValue /><DocumentID>1</DocumentID><PageNumber>1</PageNumber><ValidationPattern /><CustomTabType>Text</CustomTabType></TabStatus><TabStatus><TabType>DateSigned</TabType><Status>Signed</Status><XPosition>989</XPosition><YPosition>1493</YPosition><TabLabel>Date Signed</TabLabel><TabName>Date Signed</TabName><TabValue>7/4/2013 </TabValue><DocumentID>1</DocumentID><PageNumber>1</PageNumber></TabStatus></TabStatuses><RecipientAttachment><Attachment><Data>_</Data><Label>DSXForm</Label><Type>.xml</Type></Attachment></RecipientAttachment><AccountStatus>Active</AccountStatus><EsignAgreementInformation><AccountEsignId>79e2c3d5-971c-4e7b-8b34-575e21896435</AccountEsignId><UserEsignId>ae45b756-aa08-44d6-bc46-be76ed123a5a</UserEsignId><AgreementDate>2013-07-04T09:35:13.213</AgreementDate></EsignAgreementInformation><FormData><xfdf><fields><field name="SSN"><value>_</value></field><field name="FirstName"><value>_</value></field><field name="LastName"><value>_</value></field><field name="Data Field 5"><value>1</value></field><field name="Exemptions"><value>Single</value></field><field name="Address"><value /></field><field name="DateSigned"><value>7/4/2013 </value></field></fields></xfdf></FormData><RecipientId>1c70c533-4787-4ed2-8d0f-3b56e5bad87a</RecipientId></RecipientStatus></RecipientStatuses><TimeGenerated>2013-07-09T07:02:59.5158647</TimeGenerated><EnvelopeID>daff200b-0d82-480a-83d1-e253d50e4cbb</EnvelopeID><Subject>_</Subject><UserName>_</UserName><Email>_</Email><Status>Completed</Status><Created>2013-07-03T13:36:58.523</Created><Sent>2013-07-03T13:36:59.303</Sent><Delivered>2013-07-04T09:35:13.323</Delivered><Signed>2013-07-04T10:01:21.507</Signed><Completed>2013-07-04T10:01:21.507</Completed><ACStatus>Original</ACStatus><ACStatusDate>2013-07-03T13:36:58.523</ACStatusDate><ACHolder>Onboarding</ACHolder><ACHolderEmail>_</ACHolderEmail><ACHolderLocation>DocuSign</ACHolderLocation><SigningLocation>Online</SigningLocation><SenderIPAddress>_</SenderIPAddress><EnvelopePDFHash /><CustomFields><CustomField><Name>taskId</Name><Show>True</Show><Required>True</Required><Value>CDFA8755-1FE4-E211-80E5-005056A930BA</Value></CustomField></CustomFields><AutoNavigation>true</AutoNavigation><EnvelopeIdStamping>true</EnvelopeIdStamping><AuthoritativeCopy>false</AuthoritativeCopy><DocumentStatuses><DocumentStatus><ID>1</ID><Name>fw4.pdf</Name><TemplateName>W4</TemplateName><Sequence>1</Sequence></DocumentStatus></DocumentStatuses></EnvelopeStatus><DocumentPDFs><DocumentPDF><Name>fw4.pdf</Name><PDFBytes>_____________________________________________________________</PDFBytes><DocumentType>CONTENT</DocumentType></DocumentPDF></DocumentPDFs></DocuSignEnvelopeInformation>_____________________________________________________________</PDFBytes><DocumentType>CONTENT</DocumentType></DocumentPDF></DocumentPDFs></DocuSignEnvelopeInformation>
The errror is after the first closing tag, additional (different) PDFBytes and tags are given.
Why is data sent after the closing DocuSignEnvelopeInformation tag?
Republishing the XML for this envelope should help determine if it was a one off or if there's a bug with the Connect service. You should be able to republish the XML through your DocuSign Console settings, if you do that do you still get malformed XML?

Resources