# Production guide — Bring supplier availability into Appmint

Companion to [the full course](../appengine-connect-a-custom-business-api.md). The package contains actual Gateway Manager captures, sanitized responses, and two executable JavaScript examples. It does not include a finished video.

## The opening promise

Start with the saved consultation note in `08-saved-business-note.png`. Say: “Before promising a delivery date, check the supplier and keep the answer beside the client's consultation. We will do that with a controlled supplier API and AppEngine's Notes API.” Identify Northwind as a fictional training supplier immediately. The stock count is an observed response from that fixture, not an external company's inventory.

Show the route in three beats: supplier response, validation, saved business note. Keep the native-provider extension as a later developer chapter. The successful adapter is a separate server-side program; do not animate it as a generic HTTP provider installed in Gateway Manager.

## Shot sequence

All stills and response files are in [appengine-gateway](../assets/appengine-gateway).

| Scene | Material | What the viewer must understand |
| --- | --- | --- |
| Result first | `08-saved-business-note.png` | Twelve units, three weeks, dated note, no order placed |
| Gateway orientation | `02-gateway-load-result.png` | Configurations, Integration Builder, API Playground |
| Discover providers | `03-provider-catalog.png` | A provider implementation differs from a saved company configuration |
| Check HTTP support | `04-http-search.png` | No generic HTTP provider in this checked registry |
| Understand schema | `05-smtp-schema.png` | SMTP fields are generated by the selected provider |
| Playground prerequisites | `06-playground.png` | API Key/Auth Token choices and no active integration |
| Start training supplier | `examples/supplier-fixture.mjs` | Loopback-only fixture with deliberately public test key |
| Inspect four results | `07-supplier-results.png` | Success, zero stock, wrong key and temporary failure |
| Run adapter | `examples/check-supplier.mjs`, `example-check.json` | Validate before writing; read back the exact note |
| Explain errors | `09-gateway-errors.png` | Missing provider and missing authentication are distinct |
| Extend later | Course provider-contract section | Register, configure, initialize and test an implementation |

The numbered transcript images contain actual sanitized responses displayed as text. Label them “API response transcript” throughout. They are not screenshots of a supplier dashboard or a Studio success screen.

## Record the executable example

Use a clean terminal with no shell history, credential output or unrelated processes in view. Start `supplier-fixture.mjs` in one terminal. Show its loopback address as a developer test endpoint; it must not become a customer-facing link in the narration or end card.

Call availability directly for `NW-OAK-24`. Pause on `available: 12` and `leadTimeWeeks: 3`. Then query `EMPTY` and explain why a zero count is a valid business answer. Show the wrong-key and `FAIL` results before returning to the normal SKU. Do not label either error as a successful connection.

For the adapter, show the required environment-variable names, with credential values concealed. The fixture key is intentionally public, but the AppEngine bearer is not. Explain that the adapter runs on a trusted server or an operator's terminal and that the supplier credential does not belong in a browser bundle.

Run the adapter once against a training reservation owned by the recording account. Keep the output visible until `noteVerified: true` is readable. Show the note's timestamp and the same reservation ID in the follow-up read. A second successful invocation appends another note, so do not keep rerunning the write for camera angles. For pickups, reuse the supplied evidence or create a new explicitly named training note.

Run the failure example with `FAIL` only after the normal result has been explained. The shipped example was tested with this input and exited before writing a note. Narration: “If the supplier is unavailable, we stop. We do not turn yesterday's stock into today's promise.” A future cached value needs a visible checked-at timestamp and an explicit stale-data policy.

## Native provider and email chapters

Show the actual SMTP form with empty credentials. Point to Name, Type, Use Cases, Priority, Provider, transport settings and Auth. Explain the separation between mail transport and business mailbox ownership. Do not press Test or Save during a pickup unless a separate training SMTP service and delivery destination have been prepared.

The provider extension is an implementation walkthrough supported by source, not a deployed feature demonstrated in this rehearsal. Use a diagram of registry discovery → saved configuration → initialized instance → operation dispatch. Mention that the registry currently includes helper/blank entries, so its displayed count is not a certification of working integrations.

Use the actual webhook route shape from the course. Keep the organization in the documented header/query context. Do not put it in a guessed path segment or demonstrate an unsigned arbitrary request as a real vendor delivery. Vendor signature validation and retry handling must be exercised with that vendor's implementation when a later integration is filmed.

## Review before release

Verify the registry again on the release being recorded; a generic provider may be added after this course. If it exists, record its exact fields, authentication, operation and persisted result before replacing the adapter chapter. Check the active-list error and the provider-missing response again rather than editing a failure into success.

Confirm that screenshots contain no supplier secrets, AppEngine tokens, unrelated company records or real customer details. Add captions that read the stock count and lead time aloud. Distinguish zero stock, authentication failure and temporary unavailability in words as well as color. End with the saved note and the next decision it enables: staff can discuss availability with the client, while ordering remains a separate action.