0 Replies Latest reply on Apr 29, 2016 7:09 AM by wmolina62682

    Confused about EchoSign and internal API

    wmolina62682 Level 1

      So let me preface this by saying I am totally new to EchoSign.  I have been given a .NET project to create an API around it for our internal systems.  I have begun to do some research on the REST API (which is the one we want to use) and OAuth as I'm not familiar with that either.  I'm more than a little confused about it and have a few concerns:


      * This is for an internal API/middleware tier, it may or may not be called from a webpage (it will be, but I was told to make it reusable for other services as well) so there isn't always a "redirect URL" when I try to get an OAuth token, so I'm not sure if I should just provide a "dummy" value there or what, or if I need to pass this part off to the web development team to implement instead (more on this below).


      * I'm confused on the user account thing (re: OAuth authorization), since the way this project was explained to me there are not multiple user accounts and it seems like every request needs to ask for authorization first before getting a token?  That doesn't seem to be a one-time thing to authorize "MyApp" to do, for example, agreement_read, agreement_write, agreement_send scopes.  Maybe it's the terminology but I am familiar with APIs where you authorize a single application to do certain things, and then do not need to continually authorize it because it's already authorized to do that.


      * Related to the above, it seems my app needs to basically do an Authorize/Access Token Request on every request, since the access token is limited and the requires a code obtained in the authorization step.  However, if the Authorize request requires a user to manually click a button (i.e. "Authorize") every request, I'm not sure how that will work since this project on my end is a set of service calls, and doesn't have user interaction.  It almost sounds like the web app part will need to handle the OAuth request (as said above), and then just pass the created access token to my service, so there is a physical page the user can authorize if necessary?  That's fine if it's the case, because...


      * While initially developing the app, I wanted to abstract away getting the access token until I could figure out the OAuth issues above.  So I was planning on using the access token generated via the REST API page (refreshing it if I needed to) in order to verify that my custom code can at least call the EchoSign APIs and return the data I want, and then worry about handling OAuth itself later (since it looks like it will need to be baked into the web app since it requires interaction).  However, this doesn't seem to be working.  The access token generated works fine on the REST API page itself when I hit the "Try it out!" button.  However, if I try to copy and paste that access token to a simple Console App to test the service layer I'm creating (basically just making a GET request to /agreements, with the expectation that it will return nothing since there are no documents uploaded yet), I get INVALID_ACCESS_TOKEN in the response.  So I'm confused how I can actually test the API in an app (not the Adobe web page) without going through all the OAuth hassles first.  Is there some kind of developer token or something I can use to at least see if I can GET/POST data so I can build the service layer, and then add in the OAuth stuff later since that's over my head and I'm not working on the front end parts?


      Sorry for the somewhat newbish question, I am in fact a junior developer and this is quite a large project for me to undertake.