Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Thanks Haven for the reply. I actually could use more working code samples, html samples of how simple APIs are used to speed up my learning. Would you have those? As to the APIKey, my understanding here is that in the script, you will always need to append &apiKey=xxxx as sort of the login. Is this correct?Polly, The two main external resources we have are "https://developers.workfront.com/api-docs/">The API Docs and "https://developers.workfront.com/api-docs/api-explorer/">The API Explorer . We also appear to have API Bootcamp that is held periodically depending on client interest. Unfortunately, I've been unable to determine who actually owns that training as it only happens a few times a year. If you are interested in the Bootcamp, I'd suggest submitting a help desk ticket requesting more information. You are correct about the " &apiKey=xxxx" comment. You can think of this type of authentication as transactional. Each transaction is required to have the 'apiKey' field to authenticate the request, and as soon as the request is finished you are no longer authenticated. Within Workfront there are a few options for API Key expiration, clearing, etc., which is documented on our"https://support.workfront.com/hc/en-us/articles/218484047"> support site . While there are other authentication methods, each of them has its own drawbacks. Here is some short information on those types: "https://developers.workfront.com/api-docs/#Login">Login (username/password): This is generally discouraged as locally (before transmit), you are putting that information in plain text. There are a lot of security reasons why this should be avoided. The most simple one is browser cache/history. "https://developers.workfront.com/api-docs/#Cookie">Cookie : While it is possible to get your current login cookie and provide it to the API for authentication, You can only perform GET calls using this method for security reasons which are explained within the link. "https://developers.workfront.com/api-docs/#SessionID">Session ID : After a successful login you will be given a session ID. That session ID can also be used to authenticate. Once you logout that session ID is now invalid, and a new login will provide a different session ID. This first requires some other sort of login, which is why it's not commonly used. I have seen some scripts which use login, and then store the session ID and use that for follow-up requests. For the future, we have plans to switch to SSO/SAML/OAuth methods for security reasons, but those are currently unavailable. I hope this helps!
Views
Replies
Total Likes
Views
Replies
Total Likes