API Development and System Integration

The process you need doesn't exist in your platform

What your team actually does has a step, a form or an approval your main system was never built for. The options tend to be a workaround, a change request that goes nowhere, or living with it.

You're waiting for somebody else to build it

The answer from your platform provider is that it's coming, or that enough customers would have to ask for it first. The thing you need is specific to how you work, so nobody else is asking.

Anything new has to write back to the main system

A tool that solves the problem but keeps its own copy of the data leaves you with two versions of the same thing. Six months later somebody is checking one against the other by hand.

The integration is currently a person

Somebody exports, checks and re-enters between the two systems. It works, it's reliable enough while they are there, and it's the reason nobody has looked properly at connecting them.

Featured solution

Tailored to them, not to the tool

Our client is a prestigious estate agent whose website needed to show their properties and handle customer accounts, all in their own brand and exactly the way they wanted it.

Their property data lives in Apex27, the platform estate agencies run on. The quick route would have been to drop in Apex27's built in search widget, but that would have meant bending the site to fit the tool, and settling for something generic and limited.

We built the integration on the Apex27 API instead, which gave us full control over the look and the behaviour. The site carries a property search and customer portal in the client's own branding, with radius search, saved searches, favourites, property alerts and branded email notifications flowing between the site and Apex27. Apex27 even carried out custom development of their own to support the integration.

This is what we prefer: the client gets a site built and tailored around them, not one bent to fit someone else's tool.

Outcome