Questions about responses from GET /products service of REST API

Seeing if I can switch from legacy iSDK (or hybrid) to current SDK for PHP which according to the SDK readme uses REST with ability to pass xml in to make XML-RPC Requests… not sure if that allows you to access the legacy table schema or not though. I’d like to maintain our functionality, and think it should be fairly simple as we only use the API to pull product data less than a dozen times a year (when we update items in the store), and store the data in a database for more frequent use. Can switch to JSON file instead if can get everything we need from newest SDK (REST).

I have tested the GET /products service of REST API via “TRY IT” on the Interactive REST docs page and have questions:

  1. Product Options:
    a. products_options is inaccurately empty in the response – is this because it is nested or from something else? I saw this post from about 2 and a half years ago that seems to indicate that might be the case… but I am getting information for subscription_plans which is at the same level of nesting.

    b. As far as I’ve experienced, I need to set up select options on our website so the purchaser can choose their options to be able to pass the productOptionId and productOption in the URI used for sending the product info for the desired purchase to the IS cart (as the productId alone doesn’t trigger a request for picking from the options in the cart ,even though the options are set to be required, so the product would get added to the cart without any options passed to it). This means I need to get those product options from IS after any updates to our products so I can store them and be able to pass them to the cart upon purchase. How would I do that with the current PHP SDK?

  2. Categories and Sub-categories: What does sub_category_id in the response correspond to? I’m trying to get the info of the categories and subcategories assigned to each product in the list (or in another way to match up with them if necessary). How would I get that category info for each product?

    I use those categories and subcategories in our website store, so need to pull the info from IS when there is an update to the data.

  3. How to get the HideInStore table data for the products via the current SDK? Is there an equivalent REST request, or is there a way to use the passing of xml to access legacy table schema info… or do we just have to keep using the old iSDKs for these things?

I have a script set up using a legacy iSDK that pulls all the data from various legacy tables so that the person who changes something in the products on IS when signed in via Browser can just go to the URI of my script and it will update the database on our website, so no watching for changes in IS type of script is needed. I want to adjust that to use the current PHP SDK if it’s possible to resolve the 3 issues above.

If I am understanding your question, the full legacy API/Tables are usable with the infusionsoft-php library, you just have to make sure you tell it to use the xml version of the call where the REST and XML-RPC use the same service names (from the page you linked):

Breaking Change

If you use the Contacts , Orders or Products services, there are now two different classes handling each service - one for REST, one for XML-RPC. This version of the SDK will load the REST class by default. If you still need the XML-RPC class, pass 'xml' as an argument when requesting the object: $infusionsoft->orders('xml')'

Have you seen the documentation on the XML-RPC API via the PHP library? There is a tab for the newer php library as well as the older iSDK library (as well as XML and python):

This all still fully functional. Some of it has been added to the new REST API, which is why you have the above note from the infusionsoft-php creators, but the REST API does not yet have all the features of the XML-RPC (on infusionsoft’s end, not the creators of the php libraries) so until then it is not going anywhere.

1 Like


The SDK I shared with you can be used for the iSDK and REST. The same functionality exists so what specifically do you need from the other one?

1 Like