Our organization, which is an avid user of GoToWebinar, would like to use the GoTo API to interact with their own GoToWebinar account (via the organization's website). For many API providers, this is as simple as 1) log in to your account with the API provider, 2) copy the "private API key" found in your account, 3) store that key securely in your server, 4) send that key any time you make an API request.
I understand this is not the case with GoTo, but instead an account holder must acquire tokens via OAuth2.0's Authorization Code Grant (or Implicit Grant). I have reviewed GoTo's guides and API documentation, including the migration guides and a dozen forum posts, and I have successfully made API calls via Postman.
The Authorization Code Grant is not intended for use cases like my organization's, where the organization wants to access its *own* account via API and *not* the accounts of others. Obviously, the steps described in [https://developer.goto.com/guides/HowTos/03_HOW_accessToken/] are a roundabout way of acquiring one's own credentials. GoTo's documentation seems to acknowledge this:
- "If the username and password that you use in the password grant flow doesn’t represent real end users, the authorization code flow might not be a good fit for your integration. The process for migrating clients like yours will be defined later and you can continue to use the password grant flow until then." [https://developer.goto.com/guides/References/05_Direct-Login_migration/]
However, other GoTo documentation makes clear that new accounts may *not* use the deprecated password grant flow, which apparently leaves us stuck with Authorization Code Grant.
Requiring an Authorization Code Grant is a substantial integration burden for our use case: it requires manual intervention that should be unnecessary for single-account server-to-server communication, and it requires superfluous API calls, rotating keys, and automated calls to ensure valid access and refresh tokens are always in-hand.
I'd greatly appreciate guidance on the following:
1) Am I correct that Authorization Code Grant is the only way for an organization to access *its own* GoToWebinar account via API?
2) Does GoTo plan to implement other means of access in the near future? Namely, either a simple private API key, or a OAuth2.0 grant that is actually designed for situations where a client is accessing only its own resources, and *not* the resources of users, e.g. the Client Credentials Grant.
3) How long do refresh tokens last, and at what point will the API send a new refresh token? According to the GoTo guide:
This leads me to believe that the token will only refresh itself on day 30, which means calls on day 29 will return the same (nearly expired) refresh token, and calls on day 31 will return an "invalid token" error. This is a very slim margin, and a significant burden because missing that window would require manual intervention to reauthorize my organization's server.
However, GoTo's Authentication API docs say:
This is a more lenient timeframe, though these docs do not indicate how long-lived the token is. Which is correct?
4) Is there an up-to-date Postman collection for GoToWebinar API v2? GoTo links to a collection here: [https://developer.goto.com/guides/HowTos/06_HOW_postman/], but the collection it links to [https://documenter.getpostman.com/view/3306419/SztD6TZc] appears incorrect, e.g. it references GET:historicalWebinars, which no longer exists in the API docs, and has at least one duplicate endpoint ("Create webinar 1" vs "Create webinar 1 Copy").
Finally, and most infuriating: this Postman collection linked by GoTo provides an *incorrect* base URL for the GoToWebinar API. It provides "https://api.getgo.com/" throughout, whereas the correct base URL is "https://api.getgo.com/G2W/rest/v2/" This correct URL is in the API docs, but it is not immediately apparent: it is shown nowhere in plain text, and is revealed only when one clicks on one of the HTTP verbs in the doc. This misdirection cost us a good deal of time. (There's an older collection that appears incomplete, but in several ways is more correct than the collection currently referenced by GoTo. It can be found here: [https://documenter.getpostman.com/view/7571707/S1a8yjJg#fff2bc50-beaa-4dde-976f-e9a0d4c30eb3])
Thank you for any guidance concerning the above. Hopefully, I've missed something and someone can point out my error. Otherwise, it appears the GoToWebinar API and its documentation are in rather poor shape for use cases like my organization's.
Thank you.
