APIs and Third-Party Integrations

Almost no product is built from a blank page. A food-delivery app in Lagos does not invent maps, and it does not invent a card network. It asks other people’s systems to do those jobs. The asking mechanism is an API: an application programming interface.

Think of the API as the waiter. The client’s app places an order — the payload. The other platform answers. A success is often described as a 200. A refusal might be a 400, such as insufficient funds. A failure on the far side might be a 500. You do not need to memorise the catalogue. You need to know that the number is a fact about whose system broke.

Webhooks

An ordinary API waits to be asked. A webhook speaks first. When a transfer lands, a payments company can send a message to your client’s server: money arrived, credit the wallet. If that message is missed, the user’s bank and the user’s in-app balance tell different stories. “The webhook failed” is a sentence about that gap.

Who is sued

The curriculum’s working question is the Paystack-shaped one, and it is not special to one vendor. The user contracted with your client. The user does not have a contract with the gateway. If the gateway is down for an afternoon, the user’s claim arrives at your client’s door.

That is dependency risk. The terms the user accepted, and the service agreement with the gateway, have to admit it. A limitation that pretends the client built the rails will not match the architecture. A limitation that names third-party availability, and is actually presented to the user, at least describes the system. Whether a particular clause is enforceable is a question for a qualified lawyer on the facts. This lesson only insists that you can see the dependency before you draft.