APIs and integrations: where SME systems quietly leak data

Modern SME systems rarely exist in isolation. Invoices sync to accounting software, web apps talk to payment providers, CRMs pull in leads from websites, and reporting tools aggregate everything together.

These connections – usually built using APIs and integrations – save time and reduce manual work. But they also create one of the most common and least understood sources of data leakage in small and medium-sized businesses.

This guide explains what APIs are in plain English, why integrations introduce risk, and what sensible controls SMEs should expect by default.

What an API actually is (without the jargon)

An API is simply a controlled way for one system to talk to another. Instead of logging in like a human, software uses permissions and keys to exchange data.

For example:

• Your website sends new enquiries to a CRM.
• Your web app creates invoices in accounting software.
• A mobile app uploads photos to central storage.

APIs are powerful because they automate workflows, but that power needs limits.

Why integrations are often overlooked

When commissioning bespoke systems, integrations are usually treated as functional plumbing rather than security-sensitive components.

Common assumptions include:

• “It’s just a connection between trusted systems.”
• “The third party handles security.”
• “It only exposes a small amount of data.”

In practice, poorly secured integrations can expose entire datasets or admin-level access without anyone realising.

The most common SME integration risks

Across many SME systems, the same issues appear repeatedly:

• API keys stored in plain text or shared across environments.
• Overly broad permissions that allow full data access.
• No monitoring of API activity.
• Old integrations left running long after they’re needed.

None of these issues require sophisticated attackers – they rely on basic opportunism.

Hard-coded secrets: a quiet but serious problem

One of the most dangerous patterns is embedding API keys or credentials directly in application code.

If that code is leaked, shared, or exposed accidentally, the integration can be abused without triggering normal login protections.

Secure systems store secrets:

• Outside of source code.
• Encrypted at rest.
• With access limited to the systems that truly need them.

Least privilege: giving integrations less access

Just like users, integrations should only have access to what they require. Unfortunately, many are granted full admin permissions for convenience.

A secure approach involves:

• Separate credentials per integration.
• Read-only access where possible.
• Write access limited to specific actions.

This dramatically reduces impact if an API key is compromised.

Authentication and token management

Modern APIs usually rely on access tokens rather than static passwords. That’s a good thing – but only if implemented correctly.

Secure token handling includes:

• Tokens that expire automatically.
• Refresh mechanisms that can be revoked.
• Clear separation between development and production access.

Long-lived tokens with no expiration are effectively permanent keys.

Monitoring: knowing when something goes wrong

Many SMEs have no visibility into how often their integrations are used, or whether that usage is normal.

At a minimum, systems should log:

• Which integrations access which endpoints.
• Unusual spikes in requests.
• Repeated authentication failures.

These signals often provide early warning of problems.

Failure handling and safe defaults

Integrations don’t just pose security risks when they’re working – failures can also expose data.

Examples include:

• Error messages revealing internal system details.
• Retries that unintentionally duplicate transactions.
• Fallback behaviour that bypasses validation.

Secure systems fail safely, even when third-party services misbehave.

Third-party platforms: shared responsibility

Using well-known platforms doesn’t remove responsibility from the SME or their development team.

Third-party providers typically secure their infrastructure, but:

• You control how access is granted.
• You choose what data is shared.
• You decide which credentials stay active.

Misconfiguration remains one of the leading causes of breaches.

APIs in bespoke web applications

Custom systems often expose APIs internally or externally without them being considered “public”.

Secure bespoke APIs should:

• Authenticate every request.
• Authorise actions based on role or scope.
• Rate-limit access to prevent abuse.

Internal APIs deserve just as much care as public ones.

Old integrations: the forgotten risk

Over time, systems change. Integrations are replaced, suppliers change, and workflows evolve – but access often remains.

Regular reviews should:

• Identify unused API keys.
• Disable obsolete integrations.
• Rotate credentials periodically.

Dead connections are still live attack surfaces.

Questions SMEs should ask about integrations

You don’t need to be technical to assess integration risk. Useful questions include:

• What systems are connected to this application?
• What data can each integration access?
• Can access be revoked easily?
• How would we know if something unusual was happening?

Clear answers here indicate a mature approach to system design.

Balancing automation and control

Integrations exist to reduce friction, but removing all controls can create fragility. Secure SMEs balance automation with visibility and limits.

Well-designed systems continue working efficiently without silently exposing data in the background.

Final thought

APIs and integrations are essential to modern SME systems, but they are not set-and-forget features. Treating them as first-class security considerations prevents quiet risks from becoming noisy problems.