API Integration in Kenya: What to Agree Before Connecting Systems

Your online shop records an order, the stock system reserves the items, and the accounting system needs the right sales record. Connecting these tools can reduce repeated entry, but only if everyone agrees what should move, when it should move and what happens when one system is unavailable.

For Kenyan and East African businesses comparing API integration services, the useful starting point is a specific handover between two systems. Ask for evidence that this handover works under failure, not only a demonstration in which every request succeeds. This guide helps operations managers, business owners and technical leads prepare that brief without assuming a particular vendor or platform.

What API integration does

An API is a defined interface through which software requests data or an action from another system. Integration uses that interface, together with mapping and operating rules, to connect a business process. An available API does not automatically mean that it supports every field, transaction or permission your workflow needs.

A webhook is an event notification sent by one system to another. Polling means checking for changes at intervals. A scheduled import can suit work that tolerates a delay. The right approach depends on supported interfaces and the business deadline; “real time” should have an agreed meaning rather than appear as an unexplained promise.

For provider-specific payment or tax invoicing work, use the M-PESA integration guide or eTIMS integration guide. This article covers the agreement between systems, not their individual onboarding requirements.

Write the handover before choosing a connector

Consider a hypothetical shop sending confirmed orders to an inventory application. The order number is the shared reference. The shop owns order details; the inventory application owns stock movements. A cancelled order needs an explicit release rule. A payment notification alone should not silently become permission to dispatch goods.

Draw the current sequence with the people who handle exceptions. Mark where staff retype information, compare records or decide whether work is complete. If the process itself is unclear, the workflow automation guide helps define approvals and responsibilities before you connect tools.

Seven agreements a useful integration brief needs

1. A source of truth for each field

Decide which system owns customer identifiers, product codes, quantities, amounts and transaction status. Match stable identifiers rather than names alone. Document the treatment of missing values, renamed products, merged records and deleted records. For two-way synchronisation, decide which update wins when both systems change the same field.

Ask for a mapping sample that includes an ordinary record and an awkward one. Specify units, currency representation, date format and time zone. A total that looks correct in a screen can still be wrong after conversion, rounding or an unexpected decimal format.

2. Verified interface access

Confirm that the required API or export is included in the actual subscription and permitted for the intended use. Check documentation, a test environment, supported operations, volume limits and the provider's change policy before agreeing a delivery date. If a legacy system has no suitable interface, assess a controlled file exchange or supported extension; do not assume unrestricted database access is the answer.

3. Credential ownership and minimum permissions

Use a business-controlled integration identity where the provider supports one. Give it only the access needed for the agreed records and actions. Keep production and test credentials separate, store secrets outside source code and document who can rotate or revoke them. Credentials should not depend on a departing employee's personal account.

Agree how an expired or revoked credential will be detected and who will restore access. An error should reach the responsible person without exposing tokens or private payloads in logs or notification messages.

4. Event identity, verification and ordering

For webhooks, use HTTPS and the provider's documented verification mechanism before trusting the event. Check that the event type is relevant, retain its delivery identifier and define how duplicate or late events are handled. Follow the provider's acknowledgement deadline; where appropriate, durably queue accepted work before processing it.

Do not assume events always arrive in business order. A delayed “created” event must not overwrite a later cancellation. Agree whether the receiver checks the authoritative record, compares versions or uses another supported ordering rule.

5. Bounded retries and duplicate protection

A timeout does not prove the destination did nothing. It may have created the record before the response was lost. Where supported, use an idempotency key tied to the same business operation so a retry does not create it again. Otherwise, design and test a reliable duplicate check before retrying a write.

Separate temporary network failures from invalid records or denied access. Retry suitable failures with a delay and a limit, respect documented rate limits and stop repeatedly submitting work that needs correction. Keep the original operation reference through recovery.

6. Reconciliation and a visible exception queue

Define success as a business outcome: for example, one source order has one accepted destination record with matching lines and status. A request being sent, queued or accepted for later processing is not the same as that outcome.

Compare the expected records with the destination on an agreed schedule. Exceptions need a reason, an owner, a last-attempt time and a permitted recovery action. Staff should be able to tell “waiting for confirmation” from “rejected” without asking a developer to inspect the database. The dashboards and automation service is relevant when operations needs a focused view of these exceptions.

7. Release, support and handover

Agree who owns the code or configuration, provider accounts, monitoring and support. Include a pause mechanism, a recovery procedure for queued work, an interface-change test and a controlled release process. Rollback should account for records already written to the other system; reverting code does not reverse a completed transaction.

Record the last successful sync and the age of unresolved work. Review API version changes and credential expiry as part of ongoing software support, with responsibilities and response expectations written into the scope.

Ask for these acceptance tests

Use synthetic records in a test environment. Agree the expected result before each test, and keep evidence of the record on both sides.

• Ordinary transfer: the correct fields arrive and the destination reference is recorded.
• Repeated delivery: sending the same operation again does not create a second business record.
• Lost response: the destination completes a write but the sender times out; recovery finds the existing result.
• Invalid data: the record is rejected visibly, with no silent field substitution.
• Late update: an older event cannot undo a newer accepted state.
• Outage or rate limit: work pauses or queues safely, then resumes within the agreed capacity.
• Access removed: an alert reaches the owner without exposing credentials.
• Reconciliation mismatch: staff can find, investigate and safely resolve the exception.

What to send when requesting a quotation

Prepare the names and versions of the two systems, the interface documentation, the record types, the direction of transfer and approximate daily and peak volumes. State the required delay, known data-quality problems, existing manual checks and the person who will accept the result. Share only synthetic or properly redacted sample records through an agreed channel.

Separate initial implementation from provider subscriptions, usage charges, monitoring and maintenance. A supported connector may fit a straightforward exchange. Distinctive rules or several coordinated systems may justify custom software development. Neither choice guarantees lower costs or more sales; compare the operating responsibilities as well as the first delivery.

Frequently asked questions