4

According to the Create Library Document section of their API:

createLibraryDocument is used to create a document in a user's document library. The library can be used to send the same document for signature multiple times, either through the web application or through the API.

It doesn't make it clear whether you can put something like %ProductName% in the document and find/replace it when distributing, or whether you have to upload a brand new document each time. I'm planning on using the API to send out identical agreements but with different product and company names on them.

Any idea if this is possible?

NibblyPig
  • 46,891
  • 62
  • 180
  • 311
  • 1
    Like you, I also want to do this. Unfortunately, the API still has this marked as unavailable in the v2 REST API. I'm going to attempt to upload the document each time as a transientDocument and see if the mergeFieldInfo will apply to that. – crush Dec 15 '14 at 22:42

1 Answers1

3

The question is rather old, so I'm adding this for future reference.

I was dealing with the same problem and I found a solution. Or rather a hack. Instead of createLibraryDocument I'm using sendDocument directly. It has a mergeFieldsInfo property, which according to documentation cannot be used with library documents, but would work if you pass url of file. I tried the option with the url, and it works, I have the fields prefilled in the test document.

The example request body which have worked for me:

<?xml version="1.0"?>
<sendDocument>
  <apiKey>XXXXX</apiKey>
  <senderInfo nil="true"/>
  <documentCreationInfo>
    <fileInfos>
      <FileInfo>
        <fileName>Merchant Agreement.pdf</fileName>
        <url>https://my.public.host.com/GetFinancing%20Merchant.pdf</url>
      </FileInfo>
    </fileInfos>
    <mergeFieldInfo>
      <mergeFields>
        <MergeField>
          <defaultValue>test</defaultValue>
          <fieldName>companyName</fieldName>
        </MergeField>
        <MergeField>
          <defaultValue>test</defaultValue>
          <fieldName>companyAddress</fieldName>
        </MergeField>
        <MergeField>
          <defaultValue>0123456789</defaultValue>
          <fieldName>companyPhone</fieldName>
        </MergeField>
      </mergeFields>
    </mergeFieldInfo>
    <name>Merchant Agreement</name>
    <recipients>
      <RecipientInfo>
        <email>kowalski0123@gmail.com</email>
        <role>SIGNER</role>
      </RecipientInfo>
    </recipients>
    <reminderFrequency>NEVER</reminderFrequency>
    <signatureFlow>SENDER_SIGNATURE_NOT_REQUIRED</signatureFlow>
    <signatureType>ESIGN</signatureType>
  </documentCreationInfo>
</sendDocument>
Marek Kowalski
  • 1,721
  • 9
  • 11
  • Were you trying to embed the document you were creating, or send it directly by email? I assume the latter if you are using `sendDocument`. I'm trying to create an embeddable widget with pre-populated fields, and I just spent a lot of time trawling through the EchoSign's SOAP API to see that they do not support this use-case. Which seems very limited and is pretty frustrating! – Darragh Enright Jan 07 '15 at 12:16
  • 1
    Actually I was doing both, just not in this example. My system was sending the docs by email, although during development I was using the embeded widget, because it's much faster. And pre-populating the fields definitely works. I was using the `createUrlWidget`, and passing the `prefill` parameter same way as to the `sendDocument` call. – Marek Kowalski Jan 08 '15 at 11:22
  • Interesting! I cannot see `prefill` as a documented parameter though. Is this something different that you were doing with `mergeFieldInfo` above? I'm working with `createPersonalEmbeddedWidget` and I have the same merge info as your example but it doesn't seem to be working... yet. God I hate XML. – Darragh Enright Jan 08 '15 at 15:01
  • 1
    Ah, no, sorry `prefill` is the internal name of my api, I looked into the wrong layer. So ok, I was working with the `createUrlWidget` call. Inside I had an element of `WidgetCreationInfo` which had inside `mergeFieldInfo`. So comparing to the XML above `WidgetCreationInfo` was instead of `documentCreationInfo` – Marek Kowalski Jan 09 '15 at 15:05