Tornevall Networks is currently exploring a new integration layer for ToolsAPI called ToolsAPI Platform Bridge.
The basic idea is similar to services such as IFTTT: connect systems that normally operate separately, let an event in one system trigger something in another, and make those connections manageable from one place.
ToolsAPI already communicates with several external systems today, but many of those integrations have been built for one specific purpose. Platform Bridge would provide a common foundation instead.
Connecting more than social media
The original idea started around social platforms such as Facebook and Bluesky, but it quickly became clear that the same concept can be useful far beyond social media.
A platform could just as easily be Dropbox, OneDrive, Slack, Microsoft Teams, GitHub, Bitbucket, Jira or a forum.
ToolsAPI’s existing vBulletin integration is particularly interesting here. Instead of treating the forum as a separate system, Platform Bridge could make forum activity part of larger automated workflows.
A newly published WordPress article could, for example, create a forum thread, publish a post on Bluesky and Facebook, store related material in Dropbox or OneDrive and send a notification to Slack or Teams.
The flow could also start in the other direction. A new forum thread could trigger publication elsewhere, a GitHub pull request could result in a notification or another action, and changes in Jira or Bitbucket could be connected to other services.
Triggers, conditions and actions
The planned model is deliberately simple:
Something happens -> optional conditions are checked -> one or more actions are performed.
A trigger could be a new article, forum thread, uploaded file, received message, repository change or scheduled task.
Conditions could decide whether the workflow should continue. An automation may only apply to one forum section, a particular WordPress category, a specific repository or files placed in a certain directory.
Actions could then create a thread, publish a post, send a message, upload a file, create an issue or call another ToolsAPI service.
The individual services would still work very differently behind the scenes. Platform Bridge would provide a common layer so the rest of ToolsAPI does not need to understand every external API separately.
A growing list of possible platforms
Current candidates include Facebook, Instagram, WhatsApp, Bluesky, Slack, Microsoft Teams, Dropbox, OneDrive, vBulletin, WordPress, GitHub, Bitbucket and Jira.
Other services such as Discord, Telegram, Matrix, Mastodon, GitLab, Google Drive, SharePoint and generic webhooks are also natural candidates for later integration.
Not every service provides the same possibilities, and some integrations will inevitably be easier than others. The Bridge is therefore being designed around capabilities rather than assuming that every platform can perform the same operations.
Keeping track of what happened
Automation becomes considerably less useful when nobody knows why something failed.
Platform Bridge is therefore also intended to keep a history of events and individual actions. If one automation publishes to three services and one of them fails, the successful actions should remain successful while the failed action can be retried separately.
The same tracking can also prevent loops. If ToolsAPI creates a Facebook post from a forum thread, an incoming event for that Facebook post must not accidentally create another forum thread and start the same process again.
Connections between objects can also be remembered. ToolsAPI could know that a particular WordPress article belongs to a specific forum thread, Facebook post and Bluesky post, making future updates and cross-platform management possible.
Still at an early stage
ToolsAPI Platform Bridge is currently an architecture and development concept rather than a finished service.
The first work is focused on defining a common provider model, connections, triggers, actions, event handling and the database structure needed to support them safely.
The intention is to let existing ToolsAPI integrations gradually become part of the same system while leaving room for completely new platforms later.
In other words, the interesting part is no longer simply getting ToolsAPI to talk to another API.
It is getting all of those systems to talk to each other.