This week’s SmartConnect Office Hours session focused on SmartConnect’s Generic REST Connector, the platform’s most widely used connector. Our team has focused on improvements surrounding visibility, build speed, and flexibility, allowing you to work with difficult APIs more easily.
If you’d like to see a video explaining this, check it out here:
What the Generic REST Connector Does
The Generic REST Connector lets SmartConnect connect to most generic REST APIs. It standardizes authentication, paging, and payload types through a no-code interface, so once your connection is up, it behaves much like SmartConnect’s standard first-party connectors.
Whether you’re connecting to an API SmartConnect hasn’t worked with before, using one of the provided templates, or hooking into a custom system, this gives you a more flexible option.
What’s Staying the Same
The underlying system hasn’t changed, so existing REST connectors can be imported directly into the new platform. They won’t automatically take advantage of every new feature, but the migration process itself is quick and easy.
What’s Changing
Two changes affect the building experience directly:
- REST API sources are their own source type: This is mostly a UI-level change rather than something that affects behavior.
- A simplified target mapping experience: Previously, pushing data to a REST destination required defining the fields that show up in the map and separately defining where each field goes in the JSON or XML payload. That two-step process confused users who didn’t understand why a field appeared in one place but not another. Now, defining a field once handles both the display and the mapping destination.
What’s New in SmartConnect’s Generic REST Connector
Child Call Linking
This was one of the most heavily requested features for the REST connector. It solves cases where a single API call doesn’t return enough data on its own. For example, some sales order APIs, like BigCommerce, don’t include line items unless you make a second call per order header. Child linking also allows pulling in related detail that isn’t part of a default payload, like calling a customer endpoint to retrieve an integration ID that didn’t show up originally.
Two New Authentication Types
Bearer token authentication is now a dedicated auth type. Previously, it required a hardcoded header with a plain-text token. NTLM authentication is now supported as well.
API Request Logging
Previously (especially on-premise), seeing exactly what API call SmartConnect was making often required setting up a separate tool like Fiddler. Now, request logging is built in and available across all connectors. The Generic REST Connector benefits from it the most, since it’s especially useful for troubleshooting exactly what’s being sent back and forth.
Gaps and Deprecations
XML support is still in the works. It’s still present in a few places, but the team is continuing to work on filling it in throughout the connector, since some large, popular APIs still rely on XML for certain endpoints.
Changes to the Building Experience
A few structural changes affect how you build on the Generic REST Connector.
Where the REST build experience actually differs.
| SmartConnect.com | New SmartConnect |
| REST API sources configured underneath the Bulk Query options | REST API sources appear as a distinct source type |
| Fields and Body maintained on separate tabs of the target | Structure builder defines the JSON payload alongside the fields |
| Filtering limited to what the API itself exposes | Restrictions and calculated columns run on the source even when the source API can’t be filtered |
| Little visibility into the calls SmartConnect sent | Request logs on previews and map runs |
Walk through in New SmartConnect
Connectors
Setting up a connector still feels similar to SmartConnect.com and SmartConnect21. You name the connector, choose an authentication type, and define any custom variables.
Setup notes are still there, just repositioned slightly, and you can link data sources and integrations to the connector.
Data Source
Building a data source, whether it’s real-time or bulk, involves selecting the connector, group, and source method. The source method is the actual API call to run, and then it will go and get the data. You can also place any filters and placeholders at the bottom.
Preview with Log
This feature shows exactly what API call was made. The log shows what was sent, the headers, and the full response body, which helps pinpoint issues. For example, if a preview shows no data but the log shows the API did return data, that points to a naming or prefix mismatch rather than a missing response.
Chaining Calls
To take this one step further and pull additional details, such as a full address not included in the base customer list, you can add a second call and pass the customer ID into the URL. Chaining calls allows you to set how the two calls join and add a prefix to keep field names from colliding.
The value passed into the second call can come from a REST variable, a date variable, a global variable, or a parent field from the first call’s results.
Previewing again shows the additional detail coming through, and the request log showed the added API calls being made to pull it in.
Calculated Fields
Data sources support calculated fields for concatenating values, running math, or running JavaScript directly. This is useful for cleaning up data that doesn’t arrive in the format you need.
Restrictions
Restrictions let you filter on things the source API can’t filter on natively. For example, you can filter out entirely blank rows, or filter on a “date modified is greater than” condition even when that filter isn’t supported by the API itself.
The New Structure Builder
On the connector side, fields can now be loaded three ways:
- Added manually
- Loaded from a file (JSON or XML)
- Loaded directly from a live query call
The ability to load a field directly from a live query call is new in this release, and it allows you to pull fields straight from an API response inside SmartConnect, rather than testing the call in an external tool and copying the fields over manually.
The same loading options are available on the target side. There’s no longer a separate Fields section and body section. You get a single Structure view:
- The left side shows what appears in SmartConnect’s data target mapping.
- The right side shows the actual payload that will be sent to WooCommerce.
- The middle lets you define each field, including its type, where its value comes from, and whether it’s required.
This new structure makes manual value setting easier to configure and visualize compared to how it was in the past.
Objects & Arrays
Objects and arrays are both still supported. For something more complex, like an order, a “billing” object maps one-to-one. Line items, which have a one-to-many relationship, used to require a separate screen to configure, but now switching a field from an object to an array happens on the same screen.
Clear Branch When Empty
A new “clear branch when empty” option gives field- and object-level control over whether blank data gets sent. Previously, clearing unmapped or blank values only worked at the full top level, but now that control is available for every object individually. You can also “clear leaf when empty”, omitting the key from output when the mapped value is empty.
With this, you get granular control over which fields you send and when you send them. You can add as many nested arrays as you want and then control those with your groupings in the integration to control the number of lines that you send. Everything is still saved on the backend the same way it always was, but the new interface hides that underlying complexity so you can see everything from just one screen.
Logging at the Integration Level
Under the “Options” tab, any integration now has a “Log External Requests” checkbox. Checking it works the same way preview-with-log does, but for a live integration run.
This logging is meant for debugging and is intentionally temporary, so it only applies to the next map run. After that, the checkbox unchecks itself automatically, and any stored logs are cleared the next time the map runs.
Because these maps can be triggered from inside SmartConnect via a Webhook or API, these logs need a central place to live. That’s handled under System > Request Logs, which stores both data source previews and integration map run logs in one place.
What’s Next: Sign up for New SmartConnect Office Hours
More details on other updated connectors and New SmartConnect features will be shared regularly as we get closer to the release. If you haven’t signed up for New SmartConnect Office Hours and want to learn more about some of the other updates included, it’s not too late.
Upcoming Office Hour topics include:
- September 17: Using New SmartConnect with Salesforce
- October 1: Using New SmartConnect with NetSuite
- November 5: Using New SmartConnect with Dynamics GP
- November 12: Using New SmartConnect with Shopify
- November 19: Using New SmartConnect with Dynamics NAV
