A useful integration recipe begins with one user job and ends with evidence that a clean environment can reproduce the documented result.
Start from one complete user job
Define the recipe by the outcome a developer needs, not by the endpoint you want to describe. Name the starting state, required account or permission, sample data, final observable result, and cleanup. The workflow should be small enough to run without hidden organizational knowledge but complete enough to cross the boundaries that usually generate support questions.
Google's code-sample guidance recommends code that is correct, concise, understandable, and production-oriented. Apply that standard to the full sequence. Include authentication setup, input validation, pagination or retries when they are part of normal use, and the actual response fields the next step consumes. Omit unrelated options, but do not hide a necessary decision behind placeholder prose.
Make the environment reproducible
Pin the SDK, runtime, package manager, framework, and API version used for the test. List environment-variable names without publishing values. A development-container configuration or equivalent bootstrap script can reduce machine-specific setup, but the repository still needs a plain-language path explaining prerequisites, install, run, verify, and cleanup. The first command should start from a clean checkout.
GitHub documents how a template repository can be paired with a development-container configuration so a new project opens with the required tools and runtime. That is useful evidence, not proof by itself. Record the repository commit, container or runtime version, test account state, command, and timestamp so a later maintainer can distinguish product drift from an incomplete recipe.
Show output and one failure path
Capture the expected terminal lines, response status, or created resource that proves success. Avoid screenshots when copyable text or a machine assertion can express the same evidence. Replace volatile identifiers with clearly marked example values and state which fields will differ. A reader should know where to look and what a passing result means before running the command.
Exercise one likely failure, such as an expired credential, missing permission, invalid input, rate limit, or incompatible version. Show the observed error and the corrective action without exposing secrets. Integration Atlas prepares this record through Reality Contact, LLC. The buyer remains the authority on supported behavior and approves the recipe before it is presented as current product guidance.
Where the service stops
Reality Contact, LLC writes, tests, and packages integration documentation but does not certify the underlying product, guarantee compatibility with untested environments, operate production accounts, provide ongoing support outside the written period, or decide which product behavior the buyer promises. The buyer supplies safe access and the authoritative product contract, chooses the supported environments, resolves product ambiguities, approves each public recipe, and assigns an owner for future release-triggered maintenance. This developer-documentation and example-testing work does not replace the buyer's engineering, security, legal, compliance, or production-operations review, and it is not a promise that every customer environment will behave the same way. The buyer approves public product statements, supported combinations, credentials policy, and release status before any recipe is published.
Sources: Google developer documentation guidance for code samples; GitHub guide to template repositories for Codespaces.