From Many APIs to One Decision Engine

The Problem: Many APIs, No Brain

Most teams integrate APIs like this:

• Phone lookup API

• Email reputation API

• Watchlist API

• Court records API

Each API returns its own format.
Each team reads raw results.
Decisions are manual or inconsistent.

This is not a system.
It is a collection of calls.

You need one internal brain.

The Enrichment Brain Pattern

Your product should not call 10 vendors directly.

It should call one internal endpoint:

And receive:

• profile → merged facts + conflicts

• evidence → source + timestamp + confidence

• score → numeric risk/quality score

• reasons → human-readable explanation

• next_actions → what to do next

This is the core architecture of a multi-source data enrichment API.

Architecture Pattern

Simple pipeline:

Each block is independent.

This allows control and debugging.

Real Use-Case Scenario

A fintech app handles onboarding.

User submits:

• Phone number

• Email

• Full name

The Enrichment Brain calls:

1. Phone intelligence API

2. Email validation + reputation API

3. Watchlist API

4. Court record search

Results:

• Phone → linked to “Daniel Petrov”, confidence 0.82

• Email → linked to “Dan Petrov”, confidence 0.76

• Watchlist → no hit

• Court → one possible match: “Daniel Petrov”, same city, low confidence

Now what?

If each result is separate, the product team is confused.

But the Enrichment Brain produces this:

Example Unified Profile

Now product logic is simple:

• Score < 40 → auto approve

• 40–70 → manual review

• 70 → reject

This case goes to manual review.

Clear. Explainable. Controlled.

Decision Logic Layer

Important rule:

The Enrichment Brain does NOT approve or reject.

It outputs structured decision inputs.

Your product defines thresholds.

Example:

• High cross-source agreement → lower risk

• Conflicts between sources → increase risk

• Watchlist hit → strong penalty

All scoring must be transparent.

Never hide logic inside one vendor.

What Can Go Wrong

1. False Merge

Same name + same city ≠ same person.

Never merge entities only because:

• Common name

• Same city

• Same age range

Always require at least one strong identifier:

• Exact phone match

• Exact email match

• Government ID (if applicable)

2. Overwriting Conflicts

If one API says:

• Address: Sofia

And another says:

• Address: Plovdiv

Do not overwrite.

Store both with evidence.

Conflicts are signals.

3. Stale Signals

Court record from 2012 is different from 2025.

Always store timestamp.

Score should decay old data.

Minimal Unified Profile Checklist

Your /enrich response must include:

Profile

• Inputs

• Resolved entities

• Conflicts list

Evidence (per fact)

• Source name

• Timestamp

• Confidence score

• Reason or match rule

Scoring

• Final numeric score

• Clear reason codes

Next Actions

• auto_approve

• manual_review

• reject

• request_more_data

If any of these are missing, your system is incomplete.

How to Start Building

If you are testing enrichment APIs, start with:

Quick start:
https://espysys.com/irbis-api-quickstart-15-min/

Full API tutorial:
https://espysys.com/api-tutorial/

But remember:
Vendors are only data providers.

You must build the Brain.

Next Step

This week:

1. Design your /enrich JSON contract.

2. Define minimal evidence structure.

3. Define scoring thresholds.

4. Write simple merge rules (strong vs weak identifiers).

Do not add more vendors yet.

First build structure.

What Comes Next

Next week we go deeper:

How to store evidence correctly and manage conflicts without corrupting your profile.

That is where most systems fail.