I feel ya. I wrote a script to reformat my bank's CSV export to make it easier to work with for OnTrack [0]. I imagine it wouldn't take too much work to write a script that reformats and combines multiple sources.
The problem with this is that you don't want your free dyno to stay awake all the time because free dyno hours are capped. This tool let's you set a window to pause the requests.
In their contribution guidelines: "To add a new entry, edit the README.md file through Github's web interface or a text editor, and send a Pull Request."
Why is this the case? This stays within Heroku's limits for free tiers. They cap free dyno hours anyways so if you need your app awake all the time you have no choice but to pay.
The problem with this is that you don't want your free dyno to stay awake all the time because free dyno hours are capped. This tool let's you set a window to pause the requests.
Yeah that's a good point. I thought the data encryption made it "safe enough". I also wanted to strike a balance between nice security features and ease of use.
I am definitely no expert at security. What hosting would you recommend?
I'd like to add a little more to this - our main frustration isn't necessarily because of these technical difficulties. Communicating implementation details and 3rd party integrations can be challenging, especially if one side of the convo is not super technical. That is totally understandable, and probably inevitable.
The main reason this felt so...sucky for lack of a better term, is that we had multiple discussions about our use case and were told that this would be supported (again, this turns out not to be true? not a huge deal, it happens), and were asked to pay $20,000 upfront of which we got $0 back once realizing the original promises were not true.
As OP pointed out, 20k for a huge company like DS might not seem like much, but for a small start up like us it is. Just from a consumer perspective, this seems like a crappy way to conduct business.
1. We want the application user to sign a contract.
2. We request an embedded signing url from DS (we provide authentication creds, as well as redirect url as params - what we get back is a "special" url on DS. E.g. it is docusign.com/blahblahblah)
3. We redirect the user to the special DS url.
4. If the user signs, or refuses to sign or w/e, the user will get redirected back to our application via the redirect url we provided in our request on step #2. If the user instead decides to refresh the page, they for some reason are broken out of the signing page, and can now do whatever they want in the account as they are logged into DS's site for some reason.
HelloSign's embedded signing happens in a iframe, through their JS client. The user is never directed to HelloSign's site unless you choose to to an un-embedded workflow.
0: https://github.com/inoda/ontrack/blob/master/lib/csv_helper....