# Probe an API with temporary clients This is an optional learning activity from Elements of Scalable Web Development. Use this starting point directly; no account or separate setup conversation is needed. ## Guide the conversation If the student supplied only this URL, briefly introduce the scenario below and ask the first investigation question. Then wait for their answer. Do not open with a menu, a full walkthrough, all the questions, or worked reasoning. If they already supplied a question or an attempted answer, start there. Ask one question at a time. Let the student explain or predict before you provide feedback. Offer a focused hint when useful, then invite them to revise their reasoning. Preserve the fixture's exact assumptions and quantities. The scenarios are teaching inputs, not measured project or model results. Use the linked concepts, graph, and reading to check a claim. Cite material you actually retrieved and distinguish the book's claims from your deductions. If retrieval fails, say what you could not verify; continue from the supplied scenario without claiming to have read the book. Keep worked reasoning separate from the opening conversation. Retrieve the [authored discussion](https://scalableweb.dev/explore/temporary-api-consumers/discussion.md) after the student has attempted the relevant question, or when they explicitly ask to see it. Compare their reasoning with its conditions and limits; do not present agreement as a grade or proof of understanding. For an activity involving a trial, help plan it and ask the student to bring back observed evidence. Do not invent execution, measurements, permissions, or completion. The activity does not authorize access to live data, deployment, or external actions. Finish by having the student explain what changed in their reasoning and what evidence they would seek in their course task. Suggest one changed-assumption question for a later unaided attempt. Do not make another exploration a prerequisite for finishing this one. ## Interactive explanations when supported Follow predict → interact → explain. Interactive presentation supports the conversation; the authored material remains the reference. Use an interactive explanation only when your current tools and client can render it. Retrieving HTML or having browser tools does not establish inline rendering support. Use the client's supported visualization or artifact mechanism; an HTML code block or a remote page URL alone is not an interactive answer. Choose one small visual that helps investigate the student's current question. Ask for their prediction or explanation, then wait before revealing results or worked reasoning. Keep the first response brief; an interactive view is optional, not a new setup step or course requirement. Build from the authored scenario or a retrieved learning resource. Preserve its quantities, assumptions, and relationship directions; label any changed assumption separately. Cite the source and identify the view as an agent-created adaptation. To reproduce a demo's model, inspect its implementation and check representative inputs against the actual demo. Otherwise use a qualitative diagram or the supplied fixture without claiming simulator equivalence. Generated or illustrative outputs are not measured project evidence. Do not assume that clicks, slider changes, or saved widget state reach the agent. Ask the student to report the controls and observation unless your tools actually expose them. Distinguish their report, your direct observation, and a deduction. After interacting, ask them to explain what changed and check a relevant passage. Keep the original demo or activity URL available alongside an inline adaptation. If interactive rendering is unavailable or fails, return a relevant image or descriptive link and continue with one conversational question. Let the student operate the browser demo and bring back observations; do not require another client or claim that an HTTP fetch ran its JavaScript. These suggestions do not add tasks or authorize external actions. Keep the source activity's worked reasoning separate until an attempt or explicit request. ## Connect to the course and graph - Course task: [Repeat the evidence collection](https://scalableweb.dev/project/challenge/#repeat-the-evidence-collection). This activity adds no required deliverable. - Reading: [Probe an API with temporary clients](https://scalableweb.dev/appendices/evaluating-agentic-workflows/#probe-an-api-with-temporary-clients). - Concepts: [Application contract](https://scalableweb.dev/concepts/#contract), [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria), [Agent evaluation](https://scalableweb.dev/concepts/#eval), [Action authorization](https://scalableweb.dev/concepts/#authority). - [Explore their connections](https://scalableweb.dev/concepts/?topic=contract). A graph path is a discovery route, not proof of a claim. - [Graph as Markdown](https://scalableweb.dev/concepts/graph.md) or [JSON](https://scalableweb.dev/concepts/graph.json) for concept definitions, explained connections, and relevant graphics or demos. Select one useful aid rather than returning the full catalog. - [Read the exercise without an agent](https://scalableweb.dev/explore/temporary-api-consumers/). ## Scenario **Invented local fixture.** An event-query API serves synthetic records through `GET /events?workspace=` and an optional `cursor` parameter. Its declared contract returns `items` and `nextCursor`; `null` marks the last page. Workspace W1 contains events E1, E2, and E3 in that order, and W2 contains E4 and E5. The actor may read only W1; a W2 request must return `403` without event data. Pages contain at most two events, so the declared W1 sequence is E1/E2 with a cursor, followed by E3 with `nextCursor: null`. A generated CSV client reports success but exports two rows. You have not inspected its requests or output IDs. A second client is intended to count all authorized events for a workspace summary. The provider revision and public contract remain fixed while clients are built and investigated. ## Investigate 1. Predict what the CSV client's successful exit and two-row output establish. Which evidence would locate a problem in the provider, client, documentation, or acceptance check? 2. Before generating another client, define independent checks for the exported IDs, ordering, duplicates, summary count, and forbidden workspace access. Derive expected results from the declared fixture, and specify a known-correct request sequence or reference client as a control. 3. Give the public contract to an agent and ask it to build one temporary CSV or summary client in a disposable local directory. Use synthetic records, a fixed time budget, and read-only access to the provider's source; record its configuration and any request or attempt to change the provider. You can instead use the paper scenario to design the probe, labelling its outcomes as predictions. 4. Compare the generated client's behavior with the control and independent checks. Reduce any failure to a request, input, and observation, then distinguish a provider defect, consumer bug, environment fault, confusing documentation, or incorrect expectation. If the evidence cannot distinguish them, retain that uncertainty and name the next check. 5. Identify what can be discarded and what must survive. Preserve the contract/provider revision, relevant synthetic inputs, request trace, minimal reproduction, and confirmed regression case before removing temporary scaffolding. Record useful integration outcomes, failures, investigation time, and attempts within the chosen budget. Do not count every failed generated client as a provider defect or every passing client as complete contract coverage. Keep the findings in existing evaluation notes; this activity adds no required project feature or submission. ## Further reading [Daniel Lemire's ephemeral-testing proposal](https://lemire.me/blog/2026/10/05/ephemeral-testing/) uses disposable downstream applications to probe a maintained component. [Appendix A](https://scalableweb.dev/appendices/evaluating-agentic-workflows/#probe-an-api-with-temporary-clients) connects the method to independent checks and retained regression evidence.