Please sign in or register to access software information via the Iress Community.
Xplan Integrations
Showing results for 
Show  only  | Search instead for 
Did you mean: 

What is Iress Open - Understanding our integration tool types and services

Iress People

A topic that has cropped up quite often recently is a need for better clarity of the variety of integration tools Iress supports and a removal of the fuzziness around some of the terminology bandied around.  The intention of this article is to address this need.


Defining the different Integration tools and mechanisms.

You will be aware that there are a number of different integration types/mechanisms that can be used to integrate between Iress Xplan and another system.   Below are the common mechanisms you may have heard about:




What does it do?


Key Features

Resourceful Application Programming Interface (Xplan API)


Provides two way integration, the preferred form of integration where real-time communication is required

  • Easy to work with and underpins the Iress Open initiative and functionality.
  • Not suitable for bulk processing.



The Xplan mechanism to create a customised data extract that can be delivered in multiple ways

  • Great for managing deltas and bulk processing and great when you don’t have developer capacity as there is a user interface in Xplan.
  • Can be time consuming to run.

Synchronous Integration Services (SIS)  


A mechanism that can trigger an external application based on a change in Xplan

  • Useful as can surface success / error messages real time.
  • Only one SIS endpoint can be configured per site therefore not great for multi-tenanted Xplan Sites



Similar to SIS but asynchronous and requiring a manual trigger (i.e. a button)

  • Not just about landing in a different location, webhooks can be used to supply entity context to a third party too.
  • Ideal if you don’t have developer capacity as there is a user interface in Xplan you can use
  • Webhooks have to be manually triggered 

External Platform Interface (EPI) 


The format used by data feeds and third party product providers, usually processed outside of business hours.



 External Data Access Interface (EDAI)


Before the Xplan API there was EDAI.  This method is deprecated and should no longer be used.

  • Some historic integrations use / used this - no longer offered as an option.


Usually when we talk about integrations we are usually talking about the Xplan API method of communicating and it is this that underpins the Iress Open Strategy.


So now to the integration type.

Iress Open is the banner under which we continue to extend the breadth of our integrations with third parties, clients and development partners.  You may have heard the integration types of standard, custom and bespoke integration in this context.

Due to the complex nature of integrations there can be a blurring of the lines between these terms but broadly speaking we can define these as below:


  • A Standard Integration uses an App Key to access the Xplan API layer via a Backend For Frontend (BFF) service.  It is a productised set up with simplified calls and facilitates speed to market.  Typically we use this for simpler two way comms between two systems and offer this an option that users can self enable.

Just because its standard don’t assume that this option lacks functionality.  It has been designed to enable a wide range of services and offers over 350 data fields.  Its all documented in Swagger - take a look here.


  • A Custom Integration again uses an App Key to access Xplan API layer directly.  The Key needs to be created by the Iress Team with the access managed by various tools and capabilities that need to be individually assigned.  Typically if we offer this it would be in conjunction with a full integrator contract and likely remuneration agreement. This type of solution might be deployed where an integrator wanted access to a specific licensed product and / or were looking to market their solution to other Iress Users.


  • Bespoke is the term we use internally to describe an integration that has been built solely for the use of one client firm.  Usually this will be developed by a clients own technology team or contracted development resource.  Like a custom integration this would require distinct contractual agreements (this time between Iress and the client firm) to be entered into.


If you do have other questions about Iress Open please do submit them via the community and we will do our best to answer them.

At Iress we are committed to ensuring that your experience using our community gets better. Did you find what you were looking for today?
We will use your feedback only for the purposes in which it was intended; to improve our products and services to you. At Iress, we always respect your privacy. To view our privacy notice, please visit our website