API Overview Deck

About this template

Questions this deck has to answer

People evaluating an API do not want the endpoint list. They want to know whether it connects to their stack, how long connecting takes, and what happens when they exceed the limit. The 14 slides follow that order: cover, agenda, four dividers with four body slides, a comparison slide, metrics, a trend chart, and a closing slide. Full request and response samples belong on your docs site, linked from here.

All seven agenda lines have a slide

The agenda on slide 2 runs quick start, authentication, endpoints, rate limits, v1 and v2, key metrics and trend analysis, numbered 1 to 7 down the left. The first four items each get a divider plus a body slide, filling slides 3 to 10; the last three are single slides – the comparison on slide 11, the metric tiles on slide 12 and the bars on slide 13. Every agenda line has a screen behind it, so what to check before the talk is not the running order but whether the values on each slide match your current API spec. To add a subject the file does not carry, such as error codes or SDKs and docs, duplicate the divider-and-body pair from slides 9 and 10, continue the SECTION numbering as 05 and 06, and add the line to the agenda. For a 15-minute slot, present through rate limits and leave the last three slides in the handout.

What goes on the four body slides

Each body slide takes a title, one explanatory line and three items. The four shipped titles and what to put in them:

• Slide 4, Quick start — “five minutes from key to first call”, “free sandbox”, “copy and run the sample request”. If you claim five minutes, time it once before you print it.
• Slide 6, Authentication — “OAuth 2.0 token issuance”, “rotate keys every 90 days”, “IP allowlist available”. Adding token lifetime and refresh method cuts questions.
• Slide 8, Endpoints — “34 endpoints for read, create and update”, “JSON only”, “up to 200 records per call”. Give the categories, not the list of 34.
• Slide 10, Rate limits — “20 calls per second by default”, “429 on overage”, “raise it by agreement”. State whether the limit is per key or per organization.

Ship the metrics with their conditions

Slide 12 holds 34 public endpoints, 99.95% success rate, 68 ms average response, and a 20 calls per second limit. Bare numbers invite follow-up questions, so add the window and scope. For example: 99.95% over 90 days, excluding planned maintenance. For example: 68 ms p50, Seoul region. State whether latency is p50 or p95, because the two feel very different in production. The 20 and the 34 also appear on slides 10 and 8, so change both places together.

The trend bars go up

The trend bars read 12, 21, 29 and 34 across v1.0 to v4.0, rising with each version, and the final 34 matches the endpoint count on slide 12. The chart is built to show how the public surface grew. Put latency or error rate there and a rising bar sends the opposite message; if you need such a metric, reverse the order of values and label the axis so that lower reads as better.

What invites follow-up questions

• Listing all 34 endpoints, so nothing stands out.
• Quoting a success rate without the retry guidance and notification path for 429 and 5xx responses.
• Shipping slide 11 with the sample rate limits (60 to 600 requests per minute) and auth methods (static key to OAuth 2.0) unchanged. Developers read those two lines first, and if they contradict your reference docs the rest of the deck loses credibility.
• Editing the metric tile and the last trend bar separately. Both ship as 34, so changing one alone gets caught in the room.