Ramp API Error Triage

Overview

Turn a failing request into a sanitized, reproducible diagnosis. Separate permanent request or authority failures from transient service conditions before retrying anything.

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 returns standard HTTP status codes and may include error_v2.error_code, additional_info, and a user-facing message.
• Every API response includes x-trace-id; preserve it for correlation and support without logging authorization or sensitive payloads.
• 401 indicates a missing, expired, or invalid token; 403 indicates a valid token without sufficient scope or resource authority.
• 429 and 5xx may be retried with bounded exponential backoff; 504 means the request crossed Ramp's 60-second timeout.

Instructions

1. Capture method, sanitized URL, status, response class, x-trace-id, attempt count, environment, grant type, and requested scope without recording secrets or raw sensitive bodies.

2. Validate the request against the current endpoint schema, including required and nested fields; never rely on an unknown field being ignored.

3. For 401, refresh or reacquire the appropriate token once. For 403, compare configured scopes, token-bound scopes, app grant, user role, entity access, and endpoint authority.

4. For 429, 5xx, or 504, retry only idempotent reads or writes protected by an idempotency key, using bounded exponential backoff and jitter.

5. Reproduce in sandbox with the smallest sanitized request, preserve the trace ID and outcome, and escalate persistent vendor-side failures with the evidence bundle.

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 integration owner approves any request correction. Security approves credential rotation; finance or workflow owners approve replay of a write with business effects.

Output

A failure classification, sanitized reproducer, trace ID, authority comparison, retry/replay decision, fix, and post-fix verification.

Error Handling

Examples

Example 1

Diagnose a 403 transaction read by comparing transactions:read, the token's environment, and the authorizing user's access.

Example 2

Triage a 504 accounting export, reconcile whether the sync receipt exists, then retry only the uncommitted idempotent unit.

Validation

• The diagnosis distinguishes request, authentication, authorization, rate, timeout, and service failures.
• The evidence includes x-trace-id but no secret or sensitive business payload.
• Every retry has a bounded budget and an idempotency/reconciliation rationale.
• The corrected request is verified in sandbox or with an approved read-only production probe.

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.