Connecting your website to your organisation with APIs and integrations

Your website doesn’t have to work alone

Websites rarely need to do everything themselves.

Your organisation might already have systems managing courses, events, people, products, applications, memberships or any number of other things.

Website integrations allow information and functionality to be shared between these systems and your website, reducing the need to manage everything separately.

The question is whether your website should connect to them.

Sometimes the answer is an obvious yes. If someone spends hours copying the same information from one system to another every week, there’s probably a better way.

Other times, adding an integration can create more work than it saves.

Start with where the information belongs

One of the first things we’d want to understand is which system should be responsible for the information.

For example, if your organisation already manages hundreds of courses in a dedicated system, asking somebody to maintain another copy of every course on your website probably isn’t ideal.

The course system can remain the main source of that information, with the website using an API or another suitable method to bring across what it needs.

That doesn’t necessarily mean everything needs to come across.

The website might need the course title, start date, location and application link, while the marketing team wants more control over introductory copy, imagery and related content within WordPress.

We’ve built integrations that work in exactly this sort of way.

The key is deciding what to manage where, rather than connecting two systems just because it’s possible.

What is API integration, and how does it work?

API stands for Application Programming Interface. In simple terms, an API provides a defined way for different systems to communicate with each other.

API integration is the process of connecting those systems so they can exchange information or trigger actions without someone having to manage every step manually.

For example, a university might manage course information in a dedicated system. An API integration could allow its website to retrieve course titles, dates, locations and application links automatically.

The information continues to be managed in the original system, while the website displays what people need.

Integrations can also work in the other direction. A website enquiry form might send information to a customer relationship management (CRM) system, allowing the appropriate team to respond without manually transferring the enquiry.

WordPress includes its own REST API, which allows other applications to interact with website content. This means WordPress can both receive information from external systems and make its own content available to other applications.

The exact technology matters when we’re building the integration. For the organisation commissioning the website, the more useful questions are what information needs to move, where it needs to go and what should happen when it gets there.

Integration can remove a lot of repetitive work

One of the best reasons to connect systems is to stop people from doing jobs computers are much better suited to.

If somebody updates a course in one system and then has to make the same change on the website, you’re creating unnecessary work.

You’re also creating another opportunity for inaccuracies between the two versions. Automating that exchange can mean updating information once and using it wherever it’s needed.

That can be particularly useful for organisations managing large amounts of regularly changing information. But volume isn’t the only reason to consider it.

Even a relatively small amount of information might be worth integrating if accuracy is particularly important or changes need to appear quickly.

Common examples of website integrations

Website integrations can support all kinds of organisational processes. The most useful connections are often those that reduce duplicated work or make important information available in the right place.

Not every example requires a complex API integration. Sometimes a scheduled import, existing platform connection or simpler approach will meet the requirement.

Not everything needs to happen in real time

It’s easy to assume that an integration means information constantly moving between two systems. It doesn’t have to.

Sometimes information genuinely needs to update immediately. In other situations, checking for changes every hour or importing information overnight is more than enough.

Sometimes we might import information into WordPress rather than requesting it from another system every time someone loads a page.

The right approach depends on the information, how often it changes, how quickly updates need to appear and what happens if the other system becomes unavailable.

These decisions can make quite a difference to the performance and reliability of the finished website. The aim is to keep information sufficiently up to date without introducing unnecessary requests, dependencies or complexity.

Think about what happens when something goes wrong

Integrations introduce a dependency. If your website relies on another system and that system stops responding, what should the website do?

Ideally, the answer isn’t simply “stop working”.

Depending on the integration, we might retain previously retrieved information, show an appropriate message, retry a failed request or make sure the rest of the website continues working normally.

It’s also useful to know who is responsible for the other system.

We’ve worked on projects where an integration involves another supplier, an internal IT team or a platform that the client has very little control over. Knowing that early helps enormously.

Good documentation and access to somebody who understands the system can save a lot of detective work during development.

APIs aren’t the only option

Not every system has an API, and not every API provides everything a website needs.

Sometimes you can import data using a feed or scheduled file export. Other systems might support webhooks, where one application tells another that something has happened rather than waiting to be asked.

Older systems can require more bespoke approaches. This is why we’d be wary of specifying “API integration” as a requirement before checking what’s actually available.

Tell us which systems need to work together and what you need them to do. We can work out the most appropriate way of connecting them.

Security needs to be thought about from the beginning

Connecting systems can involve moving information between different platforms, so security and data protection need to be part of the technical planning.

Not every integration involves sensitive information. Publishing a public list of events is very different from accessing somebody’s account details.

Where authentication is required, access should be limited appropriately and credentials need to be handled securely. We also need to consider what information is actually required rather than automatically transferring everything an API makes available.

The same applies in the other direction. Information received from another system shouldn’t automatically be trusted simply because it comes through an API.

These aren’t reasons to avoid integrations. They’re reasons to design them properly.

Sometimes it’s better not to integrate

We like integrations, but we wouldn’t recommend one just for the sake of it.

Every connection between systems adds something that needs building, testing and maintaining.

APIs can change. Services can be replaced. Authentication methods can be updated. A third-party platform might experience downtime or introduce new limits.

If information changes once a year and takes five minutes to update, building an automated integration might not make sense.

Likewise, if the organisation is about to replace the system we’d be connecting to, it might be better to wait.

The amount of manual work saved, importance of the information and likely lifespan of the integration all need weighing against the complexity it introduces.

What should we know at the start of a website project?

If your new website might need to connect to other systems, you don’t need a complete technical specification before speaking to us.

It helps to know:

• which systems are involved
• what information currently lives in them?
• what information needs to appear on the website?
• whether information needs to travel in both directions
• how frequently it changes
• what currently happens when information needs updating across different systems
• whether any of it is private or sensitive
• who manages the other systems
• whether technical documentation is available
• any known API, export or integration options
• are there any existing integrations that need to be maintained or replaced

From there, we can start working out what’s possible and what makes sense.

Sometimes that results in a fairly straightforward connection.

Sometimes the best solution is more involved.

And occasionally we’ll tell you that an integration probably isn’t worth building.

That’s useful to know too.

Related Services