Integration Setup Step-by-Step Prompt Template

This prompt is designed for solutions engineers and technical writers who need to produce a numbered, step-by-step setup procedure for integrating a product with a third-party service. The primary job-to-be-done is converting a messy collection of configuration details, environment variables, and API endpoints into a clear, verifiable, and safe guide that a new developer can follow to achieve a successful integration. The ideal user is someone who understands the technical integration but needs a repeatable way to generate consistent, high-quality documentation that doesn't accidentally expose secrets or skip critical verification steps.

Use this prompt when you have a well-defined integration surface and need to produce a procedural document. It is particularly effective for documenting OAuth flows, webhook registrations, SDK initializations, or any multi-step configuration that requires credential placeholders and environment flags. You should not use this prompt for conceptual overviews, architecture decision records, or troubleshooting FAQs. It is also unsuitable when the integration steps are not yet known or are highly unstable, as the output will reflect that uncertainty. The prompt expects concrete inputs like a list of required credentials, environment variables, and the sequence of API calls or UI actions.

Before using this prompt, gather the raw integration facts: the required third-party accounts, the exact credential names, the endpoints involved, and the success criteria for each step. The harness around this prompt must enforce strict rules: no real secrets in the output, every step must include a verification checkpoint, and the final procedure must be testable. If the integration involves high-risk actions like payment processing or data deletion, the generated guide must include explicit human-approval gates. The next section provides the copy-ready template you can adapt and embed in your documentation pipeline.

The following prompt template is designed to produce a numbered, verifiable setup procedure for a third-party service integration. It enforces a structure where every step includes a success criterion, credential placeholders are explicit, and environment flags are called out. The template is ready to copy into your prompt management system, IDE, or orchestration harness. Replace each square-bracket placeholder with the specific details of the integration you are documenting before sending the prompt to the model.

textCopy
You are a solutions engineer writing integration documentation for developers.

Generate a step-by-step setup guide for integrating [PRODUCT_NAME] with [THIRD_PARTY_SERVICE_NAME].

Follow these rules strictly:
- Number every step sequentially.
- For each step, include:
  1. A clear action the developer must take.
  2. The exact environment where the action occurs (e.g., [THIRD_PARTY_SERVICE_NAME] dashboard, local terminal, [PRODUCT_NAME] admin panel).
  3. Any credential, API key, or secret reference as a placeholder in the format <YOUR_[SERVICE]_[CREDENTIAL_TYPE]> (e.g., <YOUR_STRIPE_SECRET_KEY>). Never output real or example secret values.
  4. A success criterion that is observable and testable (e.g., "You should see a 200 OK response with a valid token in the body").
- Flag any step that differs between [ENVIRONMENT_1] and [ENVIRONMENT_2] with a note like "[ENVIRONMENT_1] only:" or "[ENVIRONMENT_2] only:".
- After the final setup step, add a "Verification" section with at least one end-to-end test that confirms the integration is working.
- If the integration requires specific [NETWORK_RULES], [PERMISSIONS], or [SCOPES], list them in a "Prerequisites" section before step 1.
- If [THIRD_PARTY_SERVICE_NAME] offers a sandbox or test environment, include sandbox-specific setup steps before production steps.

Output the guide in Markdown. Use the following structure:
## Prerequisites
## Setup Steps
### Step 1: [Action Name]
...
## Verification
## Next Steps

[ADDITIONAL_CONTEXT]

To adapt this template, start by filling in the product and service names. The [ADDITIONAL_CONTEXT] placeholder is where you inject any known constraints, such as rate limits, regional availability, or known failure modes that the model should account for. If your integration has multiple authentication methods, specify the preferred one in [ADDITIONAL_CONTEXT] to prevent the model from defaulting to a less secure option. For high-risk integrations involving payment processing, user data, or infrastructure control, always route the generated output through a human review step before publication. Pair this prompt with a validation harness that scans the output for any string matching a secret pattern (e.g., sk_live_, -----BEGIN) and rejects the output if found.

This prompt is designed to be called from a documentation generation service, a CI/CD pipeline, or an internal admin tool—not as a one-off chat interaction. The harness must treat the prompt as a deterministic function: given a set of inputs (source API docs, configuration schemas, integration requirements), it produces a structured setup guide. The application layer is responsible for providing those inputs, enforcing output validation, and preventing the model from emitting secrets or hallucinated configuration values.

Input assembly is the first harness responsibility. Before calling the model, assemble the [SOURCE_MATERIAL] from the actual third-party API reference, the [CONFIGURATION_SCHEMA] from your internal config definitions, and the [ENVIRONMENT_CONTEXT] that specifies whether this is a sandbox or production guide. Strip any credential values, API keys, or internal hostnames from the source material before it reaches the prompt—the model should only see placeholder names like [API_KEY_NAME] and [OAUTH_CLIENT_ID]. Model choice matters: use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature low (0.0–0.2) to maximize procedural consistency. Enable structured output mode if your provider supports it, binding the response to a schema that enforces the numbered-step format with required fields: step_number, action, expected_result, and verification_command.

Validation and retry logic must run after every generation. First, scan the output with a regex-based secret detector that flags any string resembling an API key, token, password, or connection string. If a secret is detected, do not retry—fail the job and alert a human reviewer, because this indicates the input sanitization step failed. Second, validate that every step includes a non-empty verification_command or success criterion; if any step is missing one, retry the generation once with an explicit instruction appended to the prompt: 'Every step must include a verification checkpoint. The previous output was missing verification for step [N].' Third, check that the total step count falls within a reasonable range (5–30 steps); fewer suggests missing detail, more suggests the prompt is generating filler. Logging should capture the prompt version, model used, input source hashes, validation results, and any retry attempts. Store these in your prompt observability system so you can trace a bad setup guide back to its source material and prompt version.

Human review gates are required before publishing any integration setup guide that touches production credentials, payment systems, or PII flows. The harness should route generated guides through a review queue where a solutions engineer or technical writer can confirm that every credential placeholder matches the actual third-party service, every verification command is runnable, and no step assumes state that a new user wouldn't have. For lower-risk integrations (read-only sandbox setups, internal tool configs), automated validation plus a spot-check sampling strategy is usually sufficient. Avoid wiring this prompt directly to a 'publish' action without validation—the most common production failure is a setup guide that looks correct but contains a subtly wrong environment variable name or an outdated OAuth endpoint that breaks the user at step three.