A Support Checklist for Product Integration Questions

Integration questions are easier to solve when support receives a small, complete diagnostic package. The first reply should establish what the customer is building, where the failure occurs, what the system returned, and how the problem can be reproduced—without asking for credentials or unnecessary customer data.

Use this checklist for API, SDK, webhook, OAuth, and browser-based integration questions.

The quick support checklist

Before diagnosing the issue, collect:

• The customer’s intended outcome
• The exact step that fails
• Expected and actual behavior
• Complete error text
• HTTP method, endpoint, status code, and response body
• Request, event, or correlation ID
• Approximate timestamp and time zone
• Test or production environment
• SDK, runtime, framework, and relevant package versions
• Minimal steps or code needed to reproduce the failure
• Relevant configuration with secrets removed
• The last time the integration worked
• Recent code, account, permission, or configuration changes

GitHub’s own issue-form guidance requests current behavior, expected behavior, reproduction steps, environment details, logs, and other relevant context. That structure works equally well for private support conversations because it turns a general report into a testable problem (GitHub Docs).

1. Clarify the intended result

Start with the outcome, not the error.

A customer might say, “The API does not work,” when the actual goal is to create a subscription, synchronize a contact, receive a webhook, or sign a user in. Those workflows can involve different systems and failure points.

Ask:

• What are you trying to accomplish?
• Which documented flow or endpoint are you following?
• At which step does the result differ from your expectation?
• What did you expect to happen?
• What happened instead?

This prevents support from solving an error that is unrelated to the customer’s real objective.

2. Identify the integration surface

Record which part of the product is involved:

• REST or GraphQL API
• Official or third-party SDK
• Webhook delivery
• OAuth or another authentication flow
• Browser-side JavaScript
• Command-line tool
• No-code platform
• Sandbox, staging, or production environment

Also ask for a link to the documentation being followed. A customer may be using an old guide, a different API version, or an example intended for another environment.

3. Request the complete error evidence

Ask for the original error rather than a paraphrase. Useful evidence can include:

• HTTP status code
• Response body
• Relevant response headers
• Exception type and message
• Stack trace
• Browser console error
• Webhook delivery result
• Screenshot when the interface state matters

HTTP status codes provide an initial classification: 4xx responses generally indicate a client-side request problem, while 5xx responses indicate that the server failed to complete the request. The status code alone is not a full diagnosis, so the response body and relevant headers still matter (MDN HTTP status reference).

Do not rely only on “authentication failed” or “server error.” Preserve the exact wording, because error codes, field names, and validation details often narrow the investigation.

4. Capture identifiers and timestamps

For API and event-based systems, ask for any identifier attached to the failed operation:

• Request ID
• Correlation ID
• Trace ID
• Webhook event ID
• Delivery or attempt ID
• Job ID

Include the approximate time of failure and the customer’s time zone. These details make it possible to find the corresponding server-side record without searching through an entire day of logs.

Stripe, for example, assigns an identifier to each API request and explicitly recommends providing it when requesting help about that request (Stripe API reference). Your product may use a different name, but the diagnostic value is the same.

5. Record the environment and versions

Integration behavior can change across environments and dependency versions. Ask for only the details relevant to the affected component:

• Test, sandbox, staging, or production
• Operating system
• Programming language and runtime version
• SDK and API version
• Framework version
• Relevant dependency versions
• Browser and browser version
• Deployment platform, when relevant

For dependency-related problems, a small extract from a lockfile can be more reliable than a version recalled from memory. Avoid requesting a complete project archive unless the narrower evidence is insufficient and there is an approved secure process for receiving it.

6. Ask for a minimal reproduction

A minimal reproduction should show the smallest request or code path that still fails. It might be:

• A redacted curl command
• A short SDK example
• A small JSON payload
• Numbered interface steps
• A simplified webhook handler

For example:

curl --request POST "https://api.example.com/v1/widgets" \
  --header "Authorization: Bearer REDACTED" \
  --header "Content-Type: application/json" \
  --data '{"name":"Example widget"}'

The customer should include the response but replace credentials and sensitive values with clear placeholders. A minimal example separates the failing operation from application-specific code, background jobs, proxies, and unrelated dependencies.

7. Protect secrets and personal data

Never ask a customer to send:

• API keys
• Access or refresh tokens
• Passwords
• Session cookies
• Signing secrets
• Private keys
• Full authorization headers
• Unnecessary personal or production data

Bearer tokens require particular care because anyone who possesses one may be able to use it. The OAuth bearer-token standard therefore says tokens must be protected from disclosure to unintended parties (RFC 6750).

Ask customers to redact secrets while leaving useful structure visible:

Authorization: Bearer REDACTED
X-Request-Id: req_12345
Content-Type: application/json

If a secret has already been posted in a support message, follow the product’s incident procedure. Depending on the credential and exposure, that may include restricting access to the message and advising the customer to revoke or rotate the credential.

8. Apply a focused checklist for the integration type

API requests

Collect:

• HTTP method and endpoint
• API version
• Redacted request headers
• Request body or query parameters
• Status code
• Response body and relevant headers
• Request ID and timestamp

Check authentication, permissions, resource ownership, parameter format, version compatibility, and rate-limit headers. Do not assume that a 404 always means the URL is wrong: some APIs intentionally return 404 for private resources when the caller lacks access. GitHub documents this behavior in its REST API troubleshooting guide (GitHub Docs).

SDK problems

Collect:

• SDK name and version
• Language and runtime version
• Relevant dependencies
• Minimal code sample
• Full exception and stack trace
• Whether the equivalent direct API request works

Comparing the SDK call with a direct HTTP request can help distinguish an API problem from SDK configuration, serialization, or runtime behavior.

Webhook problems

Collect:

• Event type and event ID
• Delivery attempt ID
• Destination endpoint
• Delivery timestamp
• Returned HTTP status
• Response body
• Relevant receiver logs
• Whether signature verification failed
• Whether the event was missing, delayed, duplicated, or rejected

Avoid concluding that no webhook was sent merely because the application did not process it. The failure could occur during delivery, verification, parsing, queueing, or downstream processing.

OAuth and authentication

Collect:

• Authorization flow being used
• Redirect URI
• Requested scopes
• Returned error code and description
• The stage where the flow stops
• Whether the problem affects every account or only some accounts

Request metadata, not credentials. Confirm exact redirect URI matching, required permissions, token environment, expiration, and account authorization.

Browser and CORS errors

Collect:

• Page origin
• Requested URL and method
• Browser and version
• Console error
• Network-panel request and response details
• Whether cookies or other credentials are included

For security reasons, JavaScript receives limited detail about CORS failures; the browser console is needed to see the more specific reason. Many CORS problems must ultimately be fixed in server configuration (MDN CORS errors).

9. Classify the likely cause before replying

Once the evidence is available, place the issue in a working category:

• Customer implementation error
• Missing or incorrect configuration
• Authentication or permission problem
• Version incompatibility
• Rate limiting
• Product defect
• Service incident
• Documentation gap
• Unsupported use case
• Still undetermined

This classification is an internal hypothesis, not a verdict. Change it when new evidence contradicts it.

Before blaming the integration, check relevant service status, recent deployments, known incidents, API changes, and similar reports. Before declaring a product bug, confirm that the documented request can be reproduced under comparable conditions.

10. Write a reply with one clear next step

A useful support reply should:

1. Restate the goal and failure point.
2. Confirm the evidence already received.
3. Explain what the evidence indicates.
4. Separate confirmed facts from the current hypothesis.
5. Give one ordered set of next steps.
6. Say what information is still needed.
7. Warn the customer not to send secrets.

Hypothetical support reply

You are trying to create a widget through the Node SDK, but the request returns 403 Forbidden in production while it succeeds in the test environment.

>

The different result suggests that the production credential, account permissions, or resource ownership may be involved. Please send the SDK version, the production request ID, the approximate failure time with time zone, and the response body. Redact the API key and any personal data.

>

If possible, also confirm whether the production credential has permission to create widgets. There is no need to send the credential itself.

The reply does not present the hypothesis as a confirmed cause. It explains why the requested information matters and gives the customer a manageable next step.

A reusable intake template

**Goal**
What are you trying to build or complete?

**Failure point**
Which exact step fails?

**Expected result**
What did you expect to happen?

**Actual result**
What happened instead?

**Error evidence**
Include the full error, status code, response body, and relevant headers.

**Request or event details**
- Request/event ID:
- Approximate time:
- Time zone:
- Environment:

**Technical environment**
- Language/runtime:
- SDK:
- Framework:
- Relevant versions:

**Reproduction**
Provide the smallest redacted request, code sample, or numbered steps that reproduce the issue.

**Recent changes**
Did this work before? What changed?

**Security**
Remove API keys, tokens, passwords, cookies, signing secrets, personal data, and other confidential values.

For a small support team, this template can be stored as a saved reply or incorporated into draft-review workflows. If an assistant such as SupportMe prepares the first response, a human should still verify the technical guidance, confirm that no unsupported product behavior was assumed, and approve the message before sending it.

References

• GitHub: Syntax for issue forms
• GitHub: Troubleshooting the REST API
• Stripe: Request IDs
• MDN: HTTP response status codes
• MDN: CORS errors
• RFC 6750: OAuth 2.0 bearer-token usage

Conclusion

Effective integration support depends on disciplined evidence collection. A clear goal, exact error, request identifier, timestamp, environment, and minimal reproduction usually provide a sound basis for diagnosis. The checklist also keeps the process safe by gathering useful context without exposing credentials or unnecessary customer data.