PHP Fatal Error

I’ve set up a PHP script to get contact info. I keep getting the error “PHP Fatal error: Call to a member function getRefreshToken() on a non-object in XX/XX/vendor/infusionsoft/php-sdk/src/Infusionsoft/Infusionsoft.php on line 266”. My token is stored on a mySQL table, and I am retrieving it just fine. Here’s that script:

//Variables passed through form
$sql = "SELECT token FROM xxxxxx WHERE tokenID = 0";

$tokenReturn = $conn->query($sql);
// Decrypt and unserialize the token object from your database
if ($tokenReturn->num_rows > 0) {
while($row = $tokenReturn->fetch_assoc()){
    $token = $row['token'];
} else {
echo "0 results";
//echo $_POST['user'];
//echo $_POST['password'];

// Set up your Infusionsoft object.
    $infusionsoft = new \Infusionsoft\Infusionsoft(array(
        'clientId'     => 'XXXXXXX',
        'clientSecret' => 'XXXXXX',
        'redirectUri'  => 'XXXXXX',

    // Set the token
    $tokenUnserial = unserialize($token);
    //$tokenUnserial = unserialize($tokenNew);


    //Get user's members
    function getMembers($infusionsoft){
        //$user = $_SESSION['id'];
        $table = 'Contact';
        $limit = 1000;
        $page = 0;
        $queryData  = array('OwnerID' => 'xxxxxx', '_AnniversaryDate' => '%' );
        $selectedFields = array('Id', 'FirstName', 'LastName', '_AnniversaryDate', 'Groups', 'Email', 'Website', 'Phone1', 'City', 'State', 'Country');
        $orderBy = 'FirstName';
        $ascending = TRUE;
        return $infusionsoft->data()->query($table, $limit, $page, $queryData, $selectedFields, $orderBy, $ascending);

    //If token is available
    if ($infusionsoft->getToken()) {
        try {

            //Get list of user's members
            $members = getMembers($infusionsoft);

        //If token is not available, refresh 
        } catch(\Infusionsoft\TokenExpiredException $e) {


            $newToken = $infusionsoft->refreshAccessToken();
            //Get list of user's members
            $members = getMembers($infusionsoft);

    //All done with call, now store new token for future call
        $_SESSION['token'] = serialize($infusionsoft->getToken());
        //$token_array = $_SESSION['token'];
        $tokenSerial = $_SESSION['token'];

        //Store $tokenSerial somewhere and/or begin making API calls
        $tokenSerial = $conn->real_escape_string($tokenSerial);

            $query = "UPDATE xxxxxx SET token = '$tokenSerial', dateposted = now() WHERE tokenID = 0" or die(mysql_error());

            if($conn->query($query) === TRUE) {
                echo "Token stored successfully, again";
                echo "Error: " . $sqlNew ."<br>" . $conn->error;

Sorry, missed you did the inline version for dependencies. I don’t see any php code that looks for the ‘code’ parameter to return?

I thought I only needed the code parameter when I’m returning from Infusionsoft. I am retrieving a previous access token from storage and refreshing it for a new one.

Also, what are some other methods for creating the dependencies?

Hi Joe,

yeah I missed the last part about retrieving an existing token.

So you’ve checked that an existing token is returning from the database right? Also, if you’re retrieving a token from the table then you are missing something if you don’t have an expiration date to check. Are you aware that tokens expire in 24 hours? Finally, are you aware that when initially get the tokens and then later refresh that there are 2 token returned? An authorization token and a refresh token. You cannot get a new set of tokens with the authorization token but rather the refresh token. Are they both in your database and is that what you are recalling from that table? If so then are you ensuring that the refresh request happens in under 24 hours and/or tracking when the expiration for those tokens exist. Finally, when refreshing you will be getting a completely new set of tokens back. You can trash the old ones and update the database with the new ones.

The other dependency approach is to use require/require_once or include/include_once

Thanks John,

I print out the retrieved token (just to make sure its working properly) and this is what I get:

string(267) “O:18:“Infusionsoft\Token”:4:{s:11:“accessToken”;s:24:“XXXXXXXXXXX”;s:12:“refreshToken”;s:24:“XXXXXXXXXXX”;s:9:“endOfLife”;i:1489846559;s:9:“extraInfo”;a:2:{s:10:“token_type”;s:6:“bearer”;s:5:“scope”;s:32:“full|”;}}”

Based on the output, this token has both an access token and refresh token. I was under the impression that once I retrieve the token from my database, I can set it (which I’ve done) and if that token is valid, run my query. If it is not, it will use that token to refresh and get a new one. I am aware of the Expiration and since I am only testing/building right now, I don’t mind having to re-authorize if needed. I’ll have to set a cron job eventually. That being said, the token is still valid as 24hrs have not passed yet, I authorized earlier today. When I go to reauthorize my app, it does not give me the link to authorize but it prints out my existing token (I added the var_dump, just so I know its working)

In your ‘catch’ you’re calling the refreshAccessToken twice (once as an assignment and once as a statement). Any reason for that? I’m going by the example on github for comparison to be sure and it doesn’t match up:

No reason for that. I pasted an older version of the code, I’ve since removed that second instance. I’ve tried with and without the additional refreshAccessToken and still same issue. I also refreshed the token through appauth, got a new token, stored it and still same error. I had this script running in a different app (no longer available) and it worked fine. I grabbed the same code, updated my cliendID and secret and now get the error.

I haven’t tried cross referencing client id/secret values with different apps and I believe the id/secret is assigned specifically to the app you set it up with in mashery. Have you tried just creating id/secret for this current app specifically?

Yes, this is a brand new ID/secret. Not running anywhere else. The app was approved this morning.

At that point then, I would ask support to look at their logs

1 Like

Thanks John. I appreciate your help.

If you post your logs, the answer may be obvious.

I had same trouble. I fixed. Thanks John :slight_smile: