Sanitized Ramp Support Bundle

Overview

Create an evidence package that Ramp support and internal responders can use without exposing credentials, card details, receipts, or unnecessary employee and financial data.

Prerequisites

• Identify the Ramp application, environment, business entities, affected data and workflows, accountable owner, and rollback boundary.
• Read references/official-docs.md and re-check endpoint schemas, scopes, limits, and support status before a live operation.
• Use synthetic fixtures or Ramp sandbox until production access and business effects are explicitly approved.
• Prepare approved secret storage and a sanitized evidence location.

Current Contract

• Ramp responses include x-trace-id, the preferred correlation handle for developer support.
• API error bodies may include error_v2.error_code, additional information, and a message.
• Webhook and deferred-task incidents need delivery/task identifiers and lifecycle state, not copied secrets or full payloads.
• Authorization failures require environment, grant, and scope metadata, but never the bearer token or client secret.

Instructions

1. Open a restricted case directory and record incident window, environment, affected endpoint or event, expected behavior, owner, and data-handling classification.

2. Capture UTC timestamps, method, sanitized path template, status, x-trace-id, error code, attempt count, latency, idempotency key hash, and application release.

3. Add a minimized schema-valid reproducer using placeholders and sandbox IDs; record grant type and scope names without credential values.

4. For webhooks or deferred tasks, include subscription/event/task identifiers, deduplication outcome, state transitions, and sanitized response metadata.

5. Run a secret/card/identity scan, obtain the data owner's sharing approval, generate checksums, and transmit only through the approved support channel.

Tool Discipline

• Use Glob to locate candidate code, manifests, fixtures, and evidence without widening scope.
• Use Grep to find relevant endpoints, fields, permissions, identifiers, errors, and stale assumptions.
• Use Read to inspect the smallest required local files and authoritative evidence.
• Use Write only for a new approved local draft, test, configuration, or evidence artifact.
• Use Edit only for a bounded approved change with a known rollback.
• Local file tools do not authorize a Ramp operation or replace owner approval.

Approval Boundaries

The incident owner approves scope; security/data owners approve external sharing. Never upload raw production bodies, receipts, PAN/CVV, tokens, or client secrets.

Output

A checksummed sanitized bundle, field manifest, reproduction steps, trace IDs, environment and release metadata, redaction scan, sharing approval, and retention deadline.

Error Handling

Examples

Example 1

Bundle a recurring 422 with one sanitized request fixture, error_v2 code, trace ID, schema version, and exact release.

Example 2

Document a webhook gap using event IDs, receive timestamps, dedupe decisions, and a reconciled object count without event bodies.

Validation

• The bundle reproduces or precisely bounds the failure.
• Trace IDs and identifiers are preserved while secret and sensitive value scans are clean.
• Every included field has an explicit diagnostic purpose.
• Sharing channel, approver, checksum, and deletion date are recorded.

Resources

• Official documentation and contract notes
• Re-check the dated contract and current OpenAPI schema before any live request.
• Treat unresolved vendor behavior, authority, or financial state as a stop condition.