ESI Starting point for new developers

I flew by the seat of my pants for a long time using the old API and MS Excel, and I’ve done some work for a friend working with the API for Guild Wars 2, but, that said, I’m still painfully new to all this.

Are there any general tutorials for how all this works?
Does ESI function similar to the old API in that you create a URL that then pulls the information?

I really like what I’m reading so far on what ESI can do, but I’m looking for a starting point.


1 Like

Maybe this thread may give you some first idea?

Maybe you’d like to play with the data? The API offer a documentation and “try it” endpoint: EVE Swagger Interface

But don’t miss this one:

Hope this helps and feel free to ask further questions.

1 Like

Are two good ones.

Im providing a service for (esi) spreadsheets.
I can also give some guidance.

1 Like

Thank you. Lot of reading to do. I’m sure I’ll have quesitons.

Ok, updating this thread.

Just want to make sure I understand the basic process here, to start.

Then, when you view the application it gives you the clientID and secret key.

Then, if I understand it right, I can create a web-page with html5, javascript, PHP, or whatever, that has the user (me) enter the clientID and secretKey (obscured), and when submitted sends the clientID and secretKey to as a long URL containing the ID and key?

If that’s accurate…then a web page is opened where the user (me in this case) is asked to confirm/accept the request.

At this point, I’m still in the dark on what happens. If the request is accepted, is that all on the evetech side, and the web-page can then start requesting information? Or does the acceptance also send information back to the web-page that I need to handle somehow?

Sorry, as mentioned earlier, my API work has been limited to either Excel spreadsheets or Javascript using JSON and a single API key for GW2. If I sound like a 2 day old newb caught in a warp bubble deep in null-sec… that’s kinda what it’s like. :slight_smile:

1 Like

Follow the steps on the dev site docs.

A short oversimplification is that when the user “logs in” via sso, usually through a button on your site/app that sends them to the login portal, there’s information in that link (99% of it will never change) that must be included. The user is presented with a list of scopes to approve or deny. If they approve the scopes, they’re redirected back to your app via the callback URI. In that redirect url, there’s a parameter that contains the authorization code you need.
Once you have that authorization code, you then send that back to SSO, including your clientid:secret, in order to obtain an access token or a token set (access+refresh). Access tokens are valid for 20 minutes, refresh tokens a lot longer. Every 20 minutes you’ll need to do nearly the same thing with the authorization code, but with the refresh token instead, to get a new access token.

1 Like

Thank you for the link.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.