Integrating Modular Finance

Working in the B2B space is a bit different from working directly with end users in many ways. One of the biggest differences for a developer at Modular Finance is that we work close together with customer IR departments and digital agencies. Since we’re a data provider, most of the systems at Modular Finance have direct APIs and/or specific components that can be integrated inside customers’ systems.

These integrations vary a lot depending on specific customer use cases or requests and can range from news feeds from MFN and stock chart widgets from Datablocks to raw streaming data feeds from Dataflow.

As a result we try to develop our APIs and widgets as simple as possible but at the same time allowing customization where desired.

Development strategy

Anyone having developed APIs for external use would surely agree that designing a good API is always harder in practice than what one might have thought at first glance. Since users of an API will have different backgrounds and vastly different technichal skill, it’s a challenge to unify all requirements with one tool. At Modular Finance we have a couple of cornerstones for API and integration design to make this process a bit easier.

  • Restrict before allow - This is a common software development pattern to encapsulate intent. When exposing any interface, we need to be careful not to hand over unintended features to the user of that interface. If we decide to support a feature, it should be a conscious choice. As a rule of thumb: All exposed features (intended/documented or not) will be used and will need to be supported down the line.
  • Sensible defaults - Even for simple integration widgets, some customization is likely to be required. We need to think carefully about what default values we use for parametrized settings. It’s important that users are able to quickly get up and running with some example code and then proceed to customize it instead of the other way around.
  • Concise documentation - We should write solid integration guides with hands-on example code. This can be surprisingly hard to get right and it’s often well worth the effort to spend some extra time on, asking colleagues for review etc.
  • Split APIs where it makes sense - We don’t need to support every use case in every widget or API. Sometimes a chart widget that just supports candlestick with a static date range is the way to go.
  • Dogfooding - Where possible, make use of our own APIs

A tiny case study

As an example of the last bullet point above, we have the News page here at This page consists of two integrations: MFN for the news feed and a subscribe widget from Datablocks.

News Integrations

There are a couple of ways to integrate these widgets. I’m a fan of the “JS-loader” approach, which also happens to be how the subscribe widget is integrated. Here’s the code for that:

// create a global settings object
window._MF = {
    data: [{
        query: '#my-subscription-widget',
        widget: 'subscribe',
        locale: 'en',
        token: {widget-specific-token-here}, // something like '7d4ee7e6-326a-45f7-838f-275ddb2f2e33'
        c: {customer-specific-token-here} // another something like 'e27a911f-74e1-4463-889a-d5530ad8ba65'
    url: {datablocks-customer-api-url-here},
    ready: false,
    render: () => window._MF.ready = true

// load dependencies by creating and inserting a <script> tag into the DOM
const scriptElement = document.createElement("script");
scriptElement.type = 'text/javascript';
scriptElement.async = true;
scriptElement.src = window._MF.url + '/assets/js/loader-v2.js';

And that’s all!

This is arguably somewhat of an unconventional approach to loading widgets, patching the window object and dynamically loading scripts, but the example is concise and quite “copy-paste:able” which is a big plus for certain users. The generated subscription-element (#my-subscription-widget) can now also be styled and treated just like any other part of the page.

Integration APIs and widgets are typically reserved for customers. If you want to know more about Datablocks or how to work with the integration toolbox don’t hesitate to contact us!


Jonas Zeitler, Developer