API
Application Programming Interface
What is an API?
- The “window” programs use to talk to each other
- Agreed rules for what to ask and how to ask it
- The basics of connecting services
What an API really changes is the line between what you build yourself and what you don’t. Maps, payments, messaging, translation, and AI responses used to tie up a development team for months. Now they are parts you can plug in the same afternoon you sign up and get a key. So the question in planning meetings shifts from “Can we build this?” to “Whose version of this feature should we use?”
In practice, you will run into a few forms. The basic one is REST, where you ask and an answer comes back. There is also GraphQL, where you request only the fields you need, and the webhook, where the other side notifies you first when something happens. For events that arrive at unpredictable times, like a completed payment or a shipment leaving, a webhook beats checking every 10 minutes. Before connecting, check three things: the authentication method, call limits, and billing unit. Terms like “60 calls per minute, 10,000 free per month” can reshape the whole design later.
It also helps to sort out the neighbors people tend to confuse. An SDK is a package that wraps an API to make it easier to use in a given programming language. A widget that drops in a whole ready-made screen is easy to attach but leaves little room to customize. Not every API comes from outside, either: adding one internal API between your order system and your inventory system can end the Excel files each department used to pass back and forth. At the evaluation stage, start by checking whether there is documentation and a sandbox (test environment).
The most common mishap is writing an API key straight into source code or a shared document. If someone uses a leaked key to call AI on your account, the bill comes to you. The second is assuming the other service will last forever. If an external API goes down for 30 minutes, your service goes down with it, and if you miss a version end-of-life notice, the integration can break overnight. Don’t just design the connection; also set retry rules, a fallback path, and usage alerts.
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building real systems
John KimInstructor John Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”The API concept has existed since the early days of software. REST, today’s de facto standard for web APIs, was defined by Roy Fielding in his 2000 doctoral dissertation.
Consider a hypothetical case: Company A, an interior materials distributor with 90 employees and annual revenue of KRW 24 billion (≈ US$17,956,000). It receives about 400 orders a day across its own online store and three open marketplaces. Every morning, two customer service staff download an Excel file from each site and copy it into the inventory system by hand. That alone took 2.5 hours a day, and because inventory wasn’t real-time, they shipped 3 wrong orders a month for products that were already sold out.
- Kim, from logistics, was digging through a marketplace seller center and found the “order lookup API” documentation. “So instead of someone clicking a download button, the system can pull the orders on its own,” Kim said in the meeting.
- Instead of outsourcing development, Lee, the in-house DX lead, spent three weeks building a script that pulls new orders from the three marketplaces’ order APIs every 10 minutes and loads them into the inventory database.
- In the second week of testing, the team hit the daily limit of 1,000 calls, and afternoon orders were delayed by 4 hours. Manager Lee dropped the full-query approach and switched to a webhook approach, where the marketplace notifies the system whenever an order is placed.
- Park, the information security manager, stepped in on seeing API keys written in the team’s shared Google Sheet. “This is like taping your bank PIN to the wall.” All keys were reissued and moved to server environment variables.
- Two months after launch, 2.5 hours of manual entry a day shrank to a 10-minute daily review, and shipping errors fell from 3 a month to zero. One customer support staffer moved to handling inquiries, cutting response wait time from 12 minutes to 4.