How A Federated Customer Lookup Works, Step By Step

The lookup begins the moment you type an email into Ziikly and press enter. Ziikly validates the address, normalizes it to the same lowercase form every tool expects, and hands it to the query layer. No data is fetched yet; this first step is simply preparing one question to ask several services.

The same question goes to every connected tool: does this email exist in your records, and if so, what do you hold for it. Each integration translates that question into its own API call using the read-only key you configured. From here on, the services are queried in parallel and nothing about the customer has been written to Ziikly yet.

A sequential lookup would ask Stripe, wait for the answer, then ask the helpdesk, wait, then ask the store. With five tools that adds each tool's latency together, and the total is the sum of five waiting games. A federated lookup sends all five questions at the same moment, so the total is roughly the slowest answer, not the sum.

Parallelism is the difference between a profile that takes five seconds and one that takes one. Stripe's response arrives, the store's response arrives and the helpdesk's response arrives at their own speeds, and Ziikly assembles the profile as each answer lands. Waiting for every response is unnecessary; the profile renders progressively as tools report back.

Each tool answers in its own shape. Stripe returns charges and customers, the helpdesk returns tickets and their states, the store returns orders and the email tool returns threads. Ziikly maps each response to the fields a customer profile expects, then groups the results by tool so you can always tell where a record came from.

The merge is the important part. The email is the join key, so a payment from Stripe and a ticket from the helpdesk for the same address land on the same profile. If two tools hold contradictory records, both are shown rather than silently resolved, because Ziikly reads live data and does not guess which source is right.

Two design choices keep lookups fast. The first is parallel calls, covered above, which makes the response time roughly the slowest tool rather than the sum of every tool. The second is that Ziikly fetches only what a profile needs, scoped by the read-only keys, so requests stay small and focused on one customer.

Smaller requests and parallel execution mean the total time is usually dominated by network round trips and the slowest provider, which for most API tools are measured in hundreds of milliseconds. A customer profile therefore appears within a second in the common case, and when one service is slower, its section appears a moment later rather than holding up the rest of the page.