I’ve tried everything I can think of and read thru the documentation 15 times and still nothing…
I’ve tried php requests, postman requests, created hundreds of client credentials, reset the oauth2 encryption key 15 times…danced around in circles with composer…and reinstalled/uninstalled every module known to man kind. ChatGPT has been utterly worthless…I’ve used the postman example in the docs 10 times and gotten no where…
1 question I have is, my client credentials aren’t generating anything other than a client ID…isn’t there supposed to be a secret key that’s generated with the client ID??
I’m just trying to generate a simple access token so i can have dialogflow make calls to read data from an employee database. No matter what I try, I can’t get it to give an access token - all i’ve seen is 401 after 401 after 401…“Unauthorized”
Can someone please, pretty pretty please, give me an example of the body that should be in the postman request to generate the access token?
Update: Progress!! HURRAY! Sanity slowly returning.
Was able to get the AuthN token after I went into the oauth tables and pulled out the client secret…then it was just add the client id, and presto…auth token.
Unfortunately, that’s as far as I’ve gotten…I tried running a bunch of the postman queries and keep getting 404 not found errors. Here’s some examples of the requests I’ve made:
{{suitecrm.url}}/Api/V8/module/Accounts/b-bd23-081f-3ce6-644f485ee063?fields[Accounts]=name,account_type > 404
{{suitecrm.url}}/V8/module/Accounts/{ID}/relationships/contacts > 404
{{suitecrm.url}}/V8/module/Accounts?fields[Accounts]=name,account_type&page[size]=4&page[number]=4&sort=name&filter[operator]=and&filter[account_type][eq]=Customer > 404 
Can’t be too irritated though…would have been a lot tougher heading to bed at 3Am if that token hadn’t finally decided to show up. TIA for any advice!
More craziness…can someone please explain to me how this is possible…
The token’s date/time is actually created AFTER the token expires?? 
What version of SuiteCRM are you using? (not the API version)? I think in SuiteCRM 8 the location of the API/V8… is different. I think it might be public/legacy/API/V8/… (I haven’t tried to setup API with version 8 of SuiteCRM, but I think this is the URL). The URL’s you are using are for SuiteCRM 7.
1 Like
7.13.3
It took a while, but I finally was able to get it all squared away…was just able to run some GET requests against the custom module i built. There’s defnitely a lot of nuances to work through if you’re a newb like me because overall the suiteCRM API interface really isn’t that complex…I was just surprised by the number of bugs/quirks I ran into:
-
The Minions of Error 500 Not sure why when I create a client secret it says to leave it blank. From what I read (which was from sources all over), it made it sound like you were supposed to leave the client credential secret blank because it’d use the key that was generated during the suiteCRM setup in the config.php file. I assume there’s a bug in there and that it’s supposed to pop the secret key to you before storing it in the DB…but I never got anything. Worked fine after I started inserting my own key using a 512-bit key generated here: https://www.allkeysgenerator.com/Random/Security-Encryption-Key-Generator.aspx - and I should mention to anyone else that has this issue…the secret key you want is actually what you feed to your DB before it encodes it. But using a key i created and then copying the id provided by suite ultimately worked w/ the client credentials.
-
Ninja Error 405 - There’s a known bug that caused my 2nd issue w/ the tokens, but it was an easy fix compared to figuring out the key gen stuff. (It might also have been fixed since I’m using a later version of suite 7.13.3). The oAuth token generated on the auth request from postman at /Api/access_token using a post request w/ the following credentials in the body:
{
“grant_type” : “client_credentials”,
“client_id” : “”,
“client_secret” : “”,
“name”: “DF” (not sure name was necessary)
}
Anyways…the token it issued was already dead by the time it was time to make requests. That’s right, when I looked at the List OAuth2 Tokens carefully, I saw the “Date Created” was approx. 3 hours AFTER the “Access Token Expires” 
The fix - go into php.ini in the apache folder and change the time zone to “UTC”, and the error went away. It only gives a session an hour to survive…tried elongating that by a few hours during testing by modifying the config-override.php file, but it didn’t work; however setting the timezone to “UTC” fixed the issue w/ my new nemesis - ninja Error 405
-
Error 401 - We Are Legion - On the verge of throwing my computer out the closest window and pulling an office space with my Louisville Slugger - I took a short nap and actually dreamed this fix to the untold number of 500 errors I’d now faced. I’d confirmed my Auth tokens were being generated, and that they were now surviving long enough to allow me to perform get requests against a custom module I’d created, but the answer was always the same from the postman…no such module exists. Reality was staring me in the face as I copied the exact module name into the exact Get request posted in the docs. 500…500…500…500…it might have well as been 500000000…
I need a break and fresh eyes…so I took a nap, and within 15 minutes it came to me. “It’s not going to throw the module doesn’t exist warning…unless it’s actually checking for the module - so suite must have changed the module name on the backend somewhere!” I flew back to my terminal in a flash…opened /var then /www then /serverroot then /custom then /modules…where was it?!? Eureka!! "EM_"preceded the folder that housed my custom module! Plugged in the updated module name and bingo - employee records.
Yesterday, I ventured into the wilderness that is SuiteCRM 7.13.3 as a coding boy 
…today, I have proven myself and emerged a coding man! 
4 Likes