sections in the article
This article is a high-level description of how the inriver REST API works and the benefits of using it.
Benefits of a REST API
Use REST API instead of RemoteManager API. The REST API is more modern and will lead to better performance, especially when working with large data sets.
The inriver REST API has multiple use cases. For instance, you can use it to:
- Build integrations in any code language, integrating inriver with other systems such as CMS, e-commerce, and ERP.
- Customize the interfaces within inriver, providing a strong framework for HTML templates like Application Templates or In-Context Editing.
- Extend Enrich PDF/Preview templates with information from other entities.
Security aspects and recommended usage of the REST API
The REST API exposes functionality that is present in both Portal and ControlCenter.
It provides endpoints for both reading and updating your iPMC data and business model.
The api key should be seen as a username + password with access to your Portal and, if generated on a user with administrator rights, also to ControlCenter!
Even though you could restrict access based on the user on which you generate the api key, we advice against using the REST API as a tool for exposing/exporting entity data to your resellers or other 3:rd parts. For such purposes we instead recommend creating Syndications and/or inbound data extensions.
Trigger syndications via REST API
It is possible to trigger syndications via the REST API, an additional option to triggering them manually in the Web Portal. This allows for building more automatic syndication processes where an external snippet of code or a schema-based extension can call and trigger the syndication in a given time interval, or on some event.
Relay system events
A customer or partner that wants to build most of their integration code in another language than C# can set up listener extensions that relay any of the events that are of interest to that specific integration.
For instance, they can set up a ChannelListener if the integration is built around a channel. A ChannelListener is a type of inriver extension. The listener can then relay the channel events that it receives to an external endpoint.
The external endpoint receiving the events is hosted by the customer or partner themselves. As long as the ChannelListener can communicate with the endpoint, often using a web request of some sort, the customer or partner can use any tech stack they prefer. Any additional calls needed to facilitate the integration can be made using the REST API, which is by design code-language agnostic.
Good to know
You are limited to ten concurrent requests when using the REST API. The limit is per environment and IP address.
If you have any questions post a comment below.
Since there is a "Good to know":
There is a timeout that we are aware of in Azure, and there is an idle timeout for 4 minutes end to end.
That means all HTTP request will have less than 4 minutes to reply.
Thanks for providing the information.
The timeout issue was for InRiver's extensions, specifically the inbound-extension. We're improving the functionality and increasing the timeslot in our future releases, see https://servicecenter.inriver.com/hc/en-us/articles/360015668500-M-1-Release-Notes-September-2020
Does IP whitelisting possible for API requests?
How do I get access to the inRiver REST Api methods/swagger? The page says "no access"...
Hi Elmar Höfinghoff,
Thanks for your question. To be able to see the REST API methods/swagger you must be a customer or a partner.
I'll create a ticket so we can discuss what you are looking for and help you in the best way possible.
Mariana Cañavera H. Same issue here. Would also like to receive the REST API methods/swagger. I'm technically investigating if InRiver would be a possible solution for our customer. It would give me good insights if I would be able to see the API spec.
Thanks in advance.
Do we have REST APIs to manage Data Models? It difficult to check data model in InRiver Control Center to update specific Entity or create/update Completeness Rules.
I saw we have Remoting APIs for Completeness Rules, but didn't found REST APIs for that.
Hi Suni Gulabani,
The available REST APIs are documented in this article: REST API methods/swagger. There is currently no support for working with Completeness rules. What you can do as a workaround is to create an inbound data extension that you can call via REST, but works with inriver via Remoting.
When studying the REST API, I noticed that it provides a asset download link. With this link, the resource can be downloaded without using the REST API key (or any login).
Isn't this exposing all resources of all customers to the internet so that they can be downloaded only with the id of the individual asset? Granted, the id is 36-character long so there are over 1056 possibilities, so finding any actual asset in that possibility space by guessing is quite unlikely (unless the id is NOT truly random).
My concern is that when the asset id is known that id grants permanent access to that resource. There is no access management that could a) show who has the access, b) show who has used the access, and c) revoke the access.
Please sign in to leave a comment.