Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
I am looking to integrate echosign or docusign with our zoho crm. So that the information that is put into the contract is transfered into our crm. We currently use Zoho CRM is there anyone that knows if this is possible? If so where could i find anyone that could do this since i do not know anything about programming?
Thanks
DocuSign can be integrated with any language / platform that can make RESTful HTTP requests. Furthermore, DocuSign has major advantages over EchoSign, such as the more features (ones that actually matter), more flexibility, a MUCH bigger network (48 Million unique users), and is available in 188 countries and 43 languages. Perhaps even more important, on average the DocuSign service has been available 99.99% for the last 5 years, EchoSign has had major publicly known outages.
So yes, you can definitely integrate with Zoho CRM and some people have probably already written custom integrations that do this. The normal path to take is to simply write your own integration using the DocuSign REST API
Also, doing a web search seems to yield several companies that can specifically integrate DocuSign + Zoho CRM for you if you are not a programmer. If you / your company is not going to be coding it yourself then check out these:
CloudWork
Zapier
And you could always use E-Lance and sites like that as well.
It's absolutely possible with DocuSign. To achieve this integration, you'd do the following:
Collect data from signers during their DocuSign signing sessions
using "DocuSign tabs" (i.e., DocuSign-specific form elements that the
sender places on the document representing text boxes, checkboxes,
dropdown-lists, etc.)
Build a "listener" application and configure DocuSign Connect to send XML messages to your listener application when an Envelope is completed.
Design/build your listener application to receive and process the DocuSign Connect messages -- in your case, "processing the DocuSign Connect messages" would mean reading the "DocuSign tabs" data in each XML message and then using the Zoho CRM API to update records in Zoho with data from the DocuSign tabs. (Note: You can also configure DocuSign Connect to include the completed documents themselves in each message -- doing so would allow your listener application to also store the completed document(s) in Zoho.)
You are right to check with the developer community before investing into any platform. The short answer is DocuSign API is your best choice. Aligning yourself with a dominant API provider will ensure that:
you can find developers easier
the bugs have been discovered by someone before you and fixed
that the platform has all of the comprehensive features and you will never be stuck.
DocuSign discussions dominate StackOverflow: https://stackoverflow.com/search?q=docusign (over 300 and most are answered) and https://stackoverflow.com/search?q=echosign (45 and half are not answered).
Elance has double the freelancers that work with DocuSign vs EchoSign.
With DocuSign DevCenter (which was named as #1 by ProgrammableWeb eSignature API report http://blog.programmableweb.com/wp-content/esignature-api-report1.pdf) you have PHP samples for 9 most common scenarios meaning that your developer can get up and going with the integration a lot faster. There are also 5 other languages there for whatever comes up.
DocuSign also have an interactive API tool iodocs.docusign.com which will allow you to debug your integration simpler.
In closing DocuSign is integrated with hundreds of applications and actually quite a few of those had to redo their integration because they picked another eSignature provider first and hit reliability issues or feature gaps. Do not make the same mistake.
Here is an incomplete list of publicly available software that integrates with DocuSign: http://www.docusign.com/partners/solution-showcase
Let us know if you have any questions.
I have integrated Zoho CRM / Zoho Creator with DocuSign before. Here's what the integration looks like:
Creator form looks up record from CRM
Creator form populates form fields with CRM record data
Creator form validate script uses DocuSign API to fill out DocuSign template with form data and send the envelope
DocuSign sends response back
Creator parses response to see if the action was successful
Contact me if you need help. This isn't super easy to set up but I've done it before.
Integrating EchoSign with ZohoCRM is absolutely possible. EchoSign has a complete set of APIs that can be used for integration. We use our own APIs to build our integrations with other systems such as Salesforce.com, Microsoft Dynamics, etc. These APIs have also be used by multiple customers to build integrations into their internal systems. We know for a fact that the APIs are sufficient to build integrations into external systems.
You can get information about the EchoSign API at https://www.echosign.adobe.com/en/products/echosign-api-dev-center.html. Additionally if you have any questions please send email to api at echosign.com and we will be able to help you with your integration.
Thanks
Mangesh
Related
I've been reviewing the DocuSign documentation to see if this feature is available through API. We currently work with one eSign vendor, OneSpan, who offers the feature of Position Extraction via PDF tags set up in the document (link below for reference). I'm curious if this same functionality is available in DocuSign and have been unable to find it within the documentation.
To give some background on the use case.. Our clients want to set up our documents with PDF tags and use those for creating eSign transactions. The goal of this is so they can be vendor agnostic since the eSign creation would rely on extracting the PDF tags as opposed to explicitly setting height/width and x/y coordinates.
OneSpan Link for Position Extraction:
https://community.onespan.com/documentation/onespan-sign/guides/feature-guides/developer/position-extraction
Edit: So just to clarify what process our clients are looking to do, and some background as well. Our clients have their applications which they use to call our gateway of APIs for creating eSign transactions. Our APIs take in a generic eSign request, which we then convert to the appropriate vendor's eSign request structure before sending it out for creation. Certain clients use certain vendors, which is why we take in a generic request and convert it depending which vendor that client is subscribed to use.
Our clients are migrating away from an old legacy eSign vendor whose X/Y origin begins at the bottom left and also renders the PDF differently during the signing ceremony. When trying to migrate to a new vendor, our clients are facing pretty heavy obstacles in converting the X/Y coordinates, and height/width, so that signatures, fields, etc. appear correctly in the document in the new eSign vendor.
We were trying to think of a way to avoid this kind of problem in the future if we were to ever switch eSign vendors again. One of the ideas we're looking into is setting up PDF tags (some vendors seem to use different terms like "text tags", "anchor tags", etc) in the document itself. So say we have a signature PDF tag with the name "signature1", and this is where the OneSpan Position Extraction comes in that I linked. They offer the ability to basically extract the positioning of that signature PDF tag using the name that was set up in the PDF (so "signature1" in this case), and use that to create the signature block for the eSigning ceremony.
DocuSign is another potential vendor we may integrate later this year, and we wanted to see if similar functionality was available. If so, this would reduce the step of our clients from having to convert X/Y coordinates and height/width when switching to a different vendor.
Yes, you can do that.
There are two ways to do that, depending on the original PDF.
One approach - using anchor tags. That would mean you look for certain words or digits (like "sign here") in the document. You position the tabs this way and you can later make an API call to determine their X/Y values
The other approach is using PDF Form Field Transformation where the PDF has meta-data that DocuSign can use to determine where to place tabs.
Again, using the same API calls, you can query the document for the resulting X/Y coordinates.
(I work for DocuSign)
Re your comment about "vendor agnostic" esignatures. That's a nice idea in theory but can lead to sub-standard solutions for the end customers. For example:
DocuSign offers built-in Responsive signing which greatly improves the usability of the signing ceremony on mobile and tablet devices. A "generic" eSignature integration that leaves out the capability enforces a more difficult user experience for the signers. DocuSign has many other features like that.
Most ISVs have competitors, and if you're adding eSignatures to your application then probably your competitors are too. In these cases, we've seen ISVs tightly integrate their application with multiple eSignature features. Later, when their ISV competitors add eSignatures too, the second ISV must either match or exceed the first ISV's eSignature integration. Otherwise, the second ISV is not competitive in the marketplace.
Bottom line is that a lowest common denominator solution can end up as a non-competitive solution.
These days I am finding myself in the position of having to implement for one of my college courses a system that should act as a giant wrapper over many communications apps like Gmail , Facebook Messenger maybe even WhatsApp .To put it simply you should have a giant web interface where you can authorize Gmail , Messenger and use them at once when required. I am thinking of going with an REST API to manage the user's services authorized by OAuth2.Also I am thinking of using Node.JS and Express.js in the backend and React.js in the frontend. I found some sweet libraries in npm that should take care of interacting with the involved APIs(https://www.npmjs.com/package/node-gmail-api this one for instance), but I am also doubtful about this approach , for example I have no idea how to keep the use notified about its incoming mails or messages for example . I am in dire need of some expertise since I forgot to mention but I am quite the newbie in this field. To sum it up for once my question is how would you implement such an infrastructure ? Is it my approach viable or I am bound to hit some really hard to overcome obstacles?
As a college exercise, it would be a really fun experiment, so it definitely worth the time you want to put into it. However, once you want to add more features, the complexity will go up pretty fast.
Here are a couple of ideas you can think of:
It's pretty clear that your system can't do more things than the capabilities exposed by the APIs of communication apps (e.g. you can't have notifications in gmail if the API doesn't have this capability).
For that reason, you should carefully study the APIs and what functionalities they expose. They have public docs that you can check out: (Gmail API, Facebook Messanger API)
Some of the apps you want to communicate with may not have an official API (e.g. WhatsApp) - those kinds of details you definitely want to know from the start.
Based on the analysis of those APIs, you should lay out a list of requirements for your system, which can be extracted from all the APIs, for example: message notifications, file transfers, user profiles, etc.
In this way, you know exactly what capabilities your system should have, and you don't end up implementing a feature that is available only in 1 API out of 4.
Also, it would be a bit challenging to design your system from a user perspective, because the apps have different usage patterns - chat apps, where messages are coming in real-time, vs email, which is not real-time communication. That's just a detail anyway, the gist of your project is to play with those APIs.
Also, it may worth checking out the Gateway Aggergation Pattern, which is related to this project - you may want the user to send a message to multiple apps, by using a single request to your service.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am not a developer.
I host an easy iPhone application where users can choose between a registration through Facebook or Instagram. Almost 90% choose the Instagram way and I don't collect any special data. Only the Firstname and Lastname. Most of the things need to be filled out anyway (like the Instagram name because I do not get this from the token or the email address).
Now my developer team told me that Instagram will stop working and we need to remove this from the app. All users most login with Facebook from now on. I am using a Flutter App which works on Android and Apple.
My App is only for a specific kind of people and I felt better to use their Instagram token for a registration because it's like a "fake check" when people know, that their "real" Instagram is connected.
4 Questions:
is it really true that Instagram shuts down this "login with Instagram" functionality?
what happens to all the people who registered with the Instagram token? if they switch from Instagram to the Facebook login it would mean that there is no link to their profile any more and they do need to register almost from scratch.
the company offered me to create a own registration/user Form but I was quite happy with the Instagram way because I do not need to save a username and a password for my app.
I also received a mail from Apple that they want to use every iPhone app to use "login with apple" functionality. Will this also be mandatory in the future?
For me the situation is very bad because it will cost a lot of money to redo everything and I would appreciate to get some help or tips how I can handle the situation.
From the docs:
Q: Why should I migrate to the Instagram Graph API platform?
A: In January 2018, we publicly announced our plans to shut down the Instagram Legacy API platform through a sequenced approach. We plan to disable the final permission remaining on the Legacy API ("Basic Permission") on June 29, 2020 and any existing apps using the Legacy API will no longer have access. We encourage you to apply for permissions to Instagram Basic Display API and migrate Legacy API calls before June 29 to avoid interruption of service to your app and business. Note that App Review submissions can take up to a week or longer to process. Refer to the developer documentation to learn more.
Source
In short, it looks like you need to migrate to the Graph API. If your developer believes there is a reason why you cannot use Instagram at all, perhaps he/she could ask a specific question about that, indicating what specific problem is being encountered.
I asked similar question, but docusign support said post our question to stackoverflow again.
My prevuis question is https://stackoverflow.com/questions/28152052/docusign-how-to-get-power-forms-from-api
There is not currently a way for REST to return this information, I believe it is in the plans to be released, I'm just not sure when.
SOAP does not have this functionality, and I don't think it's planned to add as a feature either.
When it is supported in REST the path should be:
GET https://{server}/restapi/v2/accounts/{accountId}/powerforms
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm starting to learn DocuSign to see how I can integrate it into our current solution and I need your help to pick which SOA technology to use? I know how to use both SOAP and REST and I'll use Java.
My manager asked me to select one technology to use and I need reasons to tell him why I pick one technology over the other. Here are my questions to pick one over the other.
1) Does DocuSign offer the same services for both SOAP and REST? In other words, it does not matter which technology I use, I still be able to access all services DocuSign offers???
2) Simplicity - I heard REST is simpler than SOAP???
3) Any other reasons that you have, please let me know.
Which technology do you recommend for me to use please, SOAP or REST?
Thanks
From the DocuSign perspective, it comes down to personal preference (REST vs SOAP) for the most part -- there's no single compelling/mandatory reason that you would necessarily have to choose one over the other. That being said, here are some thoughts, in no particular order:
The DocuSign SOAP API has been around longer; the DocuSign REST API is much newer. Recently, it seems, new operations are oftentimes being added only to the REST API (and not to the SOAP API. (See the first paragraph here: http://www.docusign.com/developer-center/explore/soap-api)
The operations (i.e., features/functionality) available in the DocuSign SOAP API versus the DocuSign REST API are largely the same -- but the APIs are by no means 1:1 in terms of operations/features/functionality -- there are differences between the two.
There's no reason why you can't mix SOAP and REST within your implementation. i.e., Let's say you're most comfortable working with REST, so you choose that. If you discover at some point that you need an operation that's only available in SOAP, then just make that one call using the SOAP API -- leaving all the remaining calls using REST.
DocuSign SOAP API Requests tend to be larger in size than DocuSign REST API Requests -- which is fairly typical of any SOAP versus REST comparison.
The DocuSign SOAP API might be considered more powerful (efficient?) in some ways, in that there are things you can do with a single DocuSign SOAP API call that can only be achieved by making multiple DocuSign REST API calls.
I'd recommend that you checkout the DocuSign Developer Center for more information about the DocuSign APIs: http://www.docusign.com/developer-center