Talking to your engineering team
You don't need to code. You need to communicate.
The goal of this course was never to turn you into a developer. It was to give you the vocabulary and mental models to have productive conversations with your engineering team. This lesson is the payoff.
Let's go through the situations you'll actually encounter: what your engineers say, what it means, and what you can ask next.
When your engineer says...
"We need to set up a webhook"
What it means: an external service (like Stripe or Twilio) needs to notify your server when something happens. Your team will create an endpoint on your server and register its URL with the external service.
What you can ask: "Which events do we need to subscribe to?" This helps scope the work. Subscribing to every event type is more code to write and maintain. Maybe you only need payment_intent.succeeded and don't care about customer.updated.
"The API has a rate limit of 100 requests per minute"
What it means: the external service only allows 100 API calls per minute. If you go over, requests get rejected (usually with a 429 Too Many Requests status code).
What you can ask: "Does that limit what we can do at peak traffic?" If your feature sends a notification to every user who places an order, and you get 200 orders per minute during a sale, you have a problem. This is a product constraint, not just a technical one.
"We need to handle pagination"
What it means: when you ask an API for a list of items (orders, users, products), it doesn't send everything at once. It sends them in pages, maybe 20 or 50 at a time, and you request the next page with a follow-up call.
What you can ask: "Does that affect load times for the user?" If your feature displays a list of all past orders, and each page requires a separate API call, the user might see results loading in chunks. Worth knowing during design.
"We're going to use OAuth for this integration"
What it means: instead of a simple API key, the integration requires users to log in and grant permission (like "Sign in with Google"). More complex to build, but necessary when your app needs to act on behalf of the user.
What you can ask: "What permissions are we requesting?" OAuth flows show the user a consent screen ("This app wants to access your email and calendar"). Requesting too many permissions makes users hesitate. Requesting too few means you'll need to ask again later.
"The response doesn't include that field"
What it means: the data you expected (like a user's phone number or an order's shipping address) isn't in the API response. The endpoint might not return it, or it might be in a different endpoint.
What you can ask: "Is there another endpoint that has it, or do we need to make a second call?" Sometimes getting all the data you need requires chaining two API calls together. That's normal, but it adds latency and complexity.
The glossary
Here's a quick-reference table. Every term maps to something you've learned in this course.
| Term | What it means | Example |
|---|---|---|
| Endpoint | A specific URL your app calls to do something | POST /api/orders creates a new order |
| API key | A secret string that identifies your app to the service | a]Y8kP2x... in the Authorization header |
| OAuth | A login flow where the user grants your app access to their data | "Sign in with Google" button |
| Webhook | A POST request an external service sends to your server when an event happens | Stripe notifies you when a payment succeeds |
| Rate limit | Maximum number of API calls allowed in a time window | 100 requests per minute, then you get a 429 error |
| Pagination | API returns results in pages instead of all at once | First call returns items 1-20, next call returns 21-40 |
| Payload | The data sent in the body of a request or response | The JSON object with order details |
| Sandbox | A test environment where you can try the API without real consequences | Stripe test mode with fake credit cards |
| SLA | Service Level Agreement, the provider's uptime guarantee | 99.95% uptime = about 4.4 hours of downtime per year |
| Idempotent | Sending the same request twice produces the same result (no duplicates) | Retrying a payment won't charge the customer twice |
| Polling | Repeatedly checking an API for updates instead of waiting for a webhook | Calling GET /status every 10 seconds |
| Status code | A number in the response that tells you what happened | 200 = success, 404 = not found, 429 = rate limited |
The good questions to ask
You don't need to have all the answers. But asking the right questions makes you a better collaborator. Here are the ones that engineers appreciate:
| Question | When to ask it |
|---|---|
| How long will this integration take? | When scoping a feature that depends on an external API |
| What authentication does it use? | When evaluating a new service (API key is simple, OAuth is more work) |
| Is there a sandbox or test mode? | Before committing to a provider, so your team can test safely |
| What happens if the API is down? | When the feature is critical (payments, notifications, auth) |
| Do they have webhooks for this? | When your feature needs real-time updates from the external service |
| What are the rate limits? | When the feature involves high volume (batch emails, bulk imports) |
| Can we see a sample response? | When writing specs, so you know what data is available |
These questions show your team that you understand the constraints they're working with. That's the whole point.
Key takeaways
- You don't need to write code. You need to understand the vocabulary well enough to ask good questions and make informed decisions.
- When your engineer mentions webhooks, rate limits, pagination, or OAuth, you now know what they're talking about and what to ask next.
- Keep the glossary handy. It's a reference for every technical conversation you'll have about APIs.
- The best PM question isn't "how does this work?" It's "how does this affect the user experience?"