SaaS makers · Developer activation
How to measure API activation after the first successful request
Count workspaces that retrieve a result from their own input, then return for a second job. Here’s how to tell where an integration stalls.
GimmeTheSauce editorial ·
A developer pastes your quickstart into a terminal, sees a green response and leaves. Your dashboard says “activated.” Their product still does exactly what it did yesterday.
Consider an API that renders social cards for a publisher. An editor needs a usable image attached to a story. Accepting a request is only one step. Bannerbear’s asynchronous image API makes that distinction concrete: the request can return HTTP 202 before the image exists. The caller gets the completed result by polling or receiving a webhook. Bannerbear API reference
Define what counts as a real job
For this product, write down the first success a customer could recognize: an image rendered from their own story and retrieved by their integration. You can observe generation and retrieval on your server. You may need the customer’s integration to tell you whether it actually attached the image. Keep that final step unknown if you cannot observe it.
Track these milestones against a workspace and a logical job ID. A retried request, a second download of the same image, and two people testing one workspace must each be counted correctly.
| Milestone | Evidence you can record |
|---|---|
| Sample completed | The quickstart used your sample template and fixture. |
| First real input | A customer-owned template or article ID was submitted outside the fixture. |
| First usable result | That job completed and its output was retrieved. |
| Repeat use | A different customer-owned article produced a retrieved result on a later day. |
Keep raw article text and API keys out of this ledger. You need a fixture flag, a workspace identifier, a stable job identifier and timestamps. A team that publishes monthly also needs a longer observation window than a newsroom publishing every day.
Read the loss between steps
Here’s a hypothetical cohort of 40 new workspaces, each observed for a full two weeks. Thirty completed the sample, 18 submitted a real article, 15 obtained a finished render and six retrieved it. Four of those six returned for a different article.
Nine workspaces made it from real input to finished render and stopped before retrieving the file. Interview two or three from that group. Ask them to show you the response they used and what they expected to do next. Perhaps they stored the job identifier as the image URL. Perhaps the webhook was behind authentication. The counts locate the break; a failed request trace distinguishes the fixes.
Spend the engineering day where it can teach you something
If developers consistently mistake acceptance for completion, revise the quickstart so its final line saves a real image to disk. Show one pending response and the corresponding completed response side by side. Give the developer a way to locate the job in their dashboard when the output never arrives.
For the next mature cohort, compare retrievals per finished first real render. The starting point in this example is 6/15. Also watch repeats per eligible workspace. With fifteen renders, inspect individual traces before assigning meaning to a small rate change. If retrieval improves and repeat use stays flat across several comparable cohorts, the next question is whether the image fits the customer’s publishing routine. Another rewrite of the authentication docs won’t answer that.