REST v2 - Improvements Request

[Pav]

To @Angi_Hast ,

Following on from your previous reply, I would like to suggest the following improvements to be done for REST v2, otherwise it will never meet value parity to XML-RPC. If anyone else wants to add their own comments, feel free to do so.

SQL Querying Capabilities

The main sticking point of REST, either v1 or v2, is that the Query Parameters are insufficient in a number of areas. XML-RPC has the ability to act similar to a basic SQL request. The link to the documentation is given below. Developers can apply different ways to query the data.

XML-RPC Data Table Query - xml-rpc - Keap Developer Portal

What is need for REST is the ability to run SQL Select statements so that developers can query on particular fields, or even join onto other tables to get the necessary information. I need to point out that some of your larger competitors offer this capability which get around the query limitations of their own endpoints.

Here are some recent examples of developers wanting to do querying items in REST, but are unable to do so due to the querying limitations.

Can I retrieve a product by SKU when using the PHP SDK?

Currently, it is not possible to retrieve products directly by SKU using either the new PHP SDK or Keap’s REST APIs (v1 or v2). The only way to search products by SKU is using the legacy PHP SDK with XML-RPC(which is not recomended to use because its deprecated ), for example: $product = $infusionsoft->data()->query( 'Product', // Table 5, // Limit 0, // Page ['Sku' => 'prd-299'],// Query data (search by SKU) ['Id','ProductName'…

Wildcard Filtering in REST v2

Continuing the discussion from Filter Contacts and Companies: Where can I find documentation on filtering with wildcards? Something like firstname==Jon* or email==*@domain.com REST API v2

Custom Fields Querying

In XML-RPC we have the ability to query on the Custom Fields, but in REST their is none. Over a year ago Tom Scott mentioned their ware not indexed due to technical reasons. Sorry to say, but that reply is a poor excuse,. How would developers be able to migrate to REST without being able to easily query on Custom Fields? There are integrations out there that will be querying on Custom Fields for a variety of reasons.

Looking up values in custom contact field with REST V2 API

i just test you can use query parameter ‘optional_properties’ => custom_fields in REST API V2 call and it will return the custom fields also

Other Endpoints

There has been no indication on when the Ecommerce Endpoints will be fully available as very little is offered so far. Some of the other endpoints, eg; List Subscriptions, are not available. The List Reports Endpoint is confusing when it says its deprecated, so what is the alternative to use?

REST Comments

REST v1 was meant to be the replacement for XML-RPC but feel short in a number of areas. REST v2 is meant to be designed to be the equivalent to XML-RPC, but that is falling short as well. Some of us do need to see significant improvements to be able to migrate across.

[Marion_Dorsett2 (Marion Dorsett)]

The most important thing for me is bringing the REST v2 API into parity w/ the XMLPRC. The XMLRPC legacy API key was deprecated and the API limits were reduced. Using the REST v2 requires significantly more polling requests in order to find what you’re looking for when you don’t have the specific object Id, and the query filter is limited or not available for the object. This is a setup for failure instead of success.

Webhooks that send the object data vs REST Hooks that send the API endpoint or Ids, would also be preferred.

[OmarAlmonte]

Thanks for your feedback. Here’s an update on these topics:

• Updating custom field values for tasks and notes: I’ll bring this up with our team to evaluate for future improvements.

• Get product by SKU: Our team is aware of this gap and we’re actively looking into it.

• Wildcard filtering: We’ll handle these on a case-by-case basis. If you have specific scenarios where wildcard filtering would be useful, and tied to a clear business need, we can escalate them to the team.

• Custom field filtering: This won’t be supported in v2 due to performance reasons, but it’s still something we may revisit in future versions.

• SQL querying capabilities: Not supported in v2, but we welcome feedback. If there are specific gaps or filters tied to a business need, we can review them.

• Deprecated reporting endpoints: These provide legacy Saved Search reports in REST format, rather than a full new reporting solution. We won’t extend them beyond v2, but we’ll make sure a new reporting solution is in place before retiring them.

• eCommerce endpoints: We’ve identified some missing endpoints internally. If you have specific ones in mind, I can check if they’re being considered and escalate them if needed.

• Webhooks: Our team is reviewing this, and we’ll share more details once we have updates.
  @Pav @Marion_Dorsett2