An API is the agreement two systems make so a person does not have to carry the data between them. One side publishes what you can ask. The other side asks it. You get a record back, or a clear refusal. You do not get a tour of the other database.
A menu, not the kitchen
The useful picture is a menu. It lists the dishes you can order and what arrives on the plate. It does not invite you into the kitchen to rearrange the pans. When your website needs a price from the accounts system, it should ask for the price. It should not be given a login to the books and told to look around. That difference is the whole point: a small, named request, with a small, named answer.
Most of the ones a growing firm actually needs are dull. Create a customer. Read an invoice. Mark an order dispatched. Send an SMS. Take a payment. Each of those is a call with fields, a success, and a failure. The failure matters more than the demo. A timeout, a duplicate, a code the other vendor changed on a Tuesday: that is the work.
What people call an API and is not one
Exporting a spreadsheet every evening is not an API. A person emailing a CSV is not an API. A screen scraper that breaks when the other site changes a button is not an API either, though it is often sold as one. If a human still has to notice that yesterday's file did not arrive, you have a habit, not a connection.
A login that your developer uses to "just pull the data" is also not a contract. It works until the password rotates or the other company notices a robot in their admin panel. Ask for a documented interface, with a key that can be revoked, and a page that says what the fields mean.
Where it shows up
On a typical job the API is the line between the website and Tally, or between a staff portal and the bank, or between the shop and the courier. The REST style is the common one on the web. The cost of a custom system is often these connections, not the screens. A quote that says "we will integrate" without naming the system, the fields, and the person who owns a mismatch is a quote that has not started.
When it matters on a project
It matters the day you stop retyping. If two systems must agree about a customer, an order, or a payment, write the API into the first slice. Leave it for later and the spreadsheet survives go-live, because staff will not wait. It does not matter when both jobs live in one product and the vendor already joins them. Do not commission a private interface for a report you could export once a month.
Before you sign, ask three things. What is the request? What does a failure look like on a screen a person can read? Who gets the call when the other side is down? If those answers are vague, the integration is not in the price. The longer discussion of what that build costs is in how much custom software costs.