Using another company's service through its API instead of building that capability yourself.
Why it exists
Some capabilities, payments, maps, SMS, are too hard, regulated, or costly to build yourself, yet your product needs them. Rebuilding a bank or a telco is not an option. Third-party APIs exist so you can use another company's service over the network as a building block, paying them to solve the part you should not build.
How it actually works
You will not build card processing, mapping, or SMS from scratch. You connect to a company that already did, through its API. You send them requests ("charge this card," "send this text") and handle their responses.
This is most of modern software: assembling specialist services. The trade is speed and reliability now, in exchange for dependency, cost, and being subject to their limits and outages.
A senior PM walks you through it
A junior PM, stuck
Our SMS vendor had a 40-minute outage and order confirmation texts silently failed the whole time. In the incident review I have to explain how one outside company's problem became our customers' problem, and I only half understand the dependency myself.
Every confirmation text is TiffinBox making one call out to another company's API, the SMS vendor, and paying per message. When their service is down, that call comes back as a failure and there is nothing on our side to send the text instead. Reading it is quick. Here is the exact outbound call on a normal day and the same call during their outage, so you can see precisely where the dependency broke.
TiffinBox's outbound SMS call, healthy and during the vendor outage
The confirmation call on a normal day
111.1
2:
3:927
4
5{
6"to":"+8801700000000",
7"text":"Your TiffinBox order o_5512 is confirmed."
Treating a vendor call like our own code. A 503 from api.smsvendor.com is their failure, not a TiffinBox bug, but it is still our customer who gets no text; whose fault it is and whose problem it is are different things.
Firing the call and never checking the response. If checkout does not look at the 200 versus 503, failed confirmations vanish silently, which is why nobody saw the outage until customers complained.
Forgetting the outage question in scoping. "Integrate their SMS API" is fast to say, but "what happens when it is unavailable" is the line that decides whether a vendor blip becomes a customer incident.
Ignoring the cost line. Every 200 here bills 0.35 taka; a bug that retries forever is not just a reliability problem, it runs up a real invoice with the vendor.
In the review say: "Each confirmation is an outbound call to the SMS vendor. During their outage it returned 503 and we did nothing with the failure, so the texts silently dropped. The action item is to queue and retry failed sends so their outage does not become ours." You located the dependency, read the failure, and named the fix.
Where a PM meets this
Build-versus-buy is a core PM decision; integrating is usually faster but adds a vendor you now depend on and pay.
When a third party has an outage, your feature goes down too. "What happens if their API is unavailable?" is worth asking up front.
Hear it in a meeting
"Do we build our own or integrate theirs? Integrating is two weeks, building is two months."