The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Jun 11, 2026 11:59pm

@greptile

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}

@cursor review

PR Summary

Medium Risk
Touches OAuth/auth and a server route that forwards bearer tokens and user files to Ramp; scope is additive but finance data and file handling warrant careful review.

Overview
Adds a Ramp finance integration so workflows can automate corporate spend via OAuth and 25 tools (transactions, users, cards, limits, reimbursements, bills, vendors, departments, receipts, business balance, etc.).

Wires Ramp OAuth (RAMP_CLIENT_ID / RAMP_CLIENT_SECRET, Basic-auth token refresh, business-scoped getUserInfo) and registers the Ramp block with operation-specific UI, pagination (nextStart), receipt file upload, templates/skills, docs (ramp.mdx), icons, and integrations.json catalog entry. Most API calls use shared Ramp tool helpers; receipt upload is proxied through /api/tools/ramp/upload-receipt with contract validation, internal auth, file access checks, and Ramp’s multipart format.

^{Reviewed by Cursor Bugbot for commit eceb558. Configure here.}

Greptile Summary

This PR adds a complete Ramp integration with 25 tools covering transactions, users, cards, spend limits, reimbursements, bills, departments, vendors, entities, spend programs, business info/balance, and receipts. It registers Ramp as an OAuth provider (authorization code + refresh token via Basic auth), adds the Ramp block, and routes file uploads through an internal proxy endpoint that handles multipart/form-data construction.

• 25 tools all follow the established ToolConfig pattern with accessToken marked visibility: 'hidden' (correct per codebase convention for OAuth-injected tokens) and direct Ramp API calls via buildRampHeaders/buildRampUrl helpers.
• Receipt upload goes through /api/tools/ramp/upload-receipt which validates the caller with checkInternalAuth, enforces file access with assertToolFileAccess, then constructs a sanitized multipart body before forwarding to Ramp; field values, filename, and Content-Type are all stripped of CR/LF characters.
• OAuth registration in auth.ts follows the identical pattern used by 40+ other generic OAuth providers (non-deterministic providerAccountId per authorization, getUserInfo fetches /business to synthesize a stable identity from the business ID).

Confidence Score: 5/5

This PR is safe to merge; it adds a self-contained new integration with no changes to existing logic paths.

All 25 tools follow the established codebase patterns for OAuth-backed integrations. The receipt upload route correctly validates the caller, checks file ownership, and sanitizes CR/LF characters in all user-controlled fields before embedding them in the multipart body. OAuth registration mirrors the existing 40+ provider convention. No existing code paths are modified beyond additive registration entries.

No files require special attention. The upload-receipt route is the most complex new path and it handles auth, file access, and multipart construction correctly.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Client as Client Tool (upload_receipt.ts)
    participant Internal as /api/tools/ramp/upload-receipt
    participant Storage as File Storage
    participant Ramp as Ramp API

    Client->>Internal: "POST JSON {accessToken, userId, transactionId?, file}"
    Internal->>Internal: checkInternalAuth()
    Internal->>Internal: parseRequest (Zod validation)
    Internal->>Internal: processFilesToUserFiles()
    Internal->>Internal: assertToolFileAccess(key, userId)
    Internal->>Storage: downloadFileFromStorage(userFile)
    Storage-->>Internal: fileBuffer
    Internal->>Internal: buildReceiptMultipartBody(boundary, fields, file)
    Internal->>Ramp: POST /receipts multipart/form-data
    Ramp-->>Internal: "{id} or error"
    Internal-->>Client: "{success, output: {receiptId}} or {success: false, error}"

_{Reviews (3): Last reviewed commit: "fix(ramp): sanitize multipart field valu..." | Re-trigger Greptile}

Greptile Summary

This PR adds a full Ramp integration — 25 tools covering transactions, users, cards, spend limits, reimbursements, bills, departments, vendors, entities, spend programs, business info/balance, and receipts — along with an OAuth provider registration, a custom internal upload route for the multipart Ramp receipts endpoint, a block with conditional sub-blocks and wand configs, and docs.

• OAuth & auth: Ramp is registered as a provider with Basic-auth token refresh. getUserInfo synthesises a stable business identity following the established random-suffix ID pattern used by every other provider in this file.
• Receipt upload route (/api/tools/ramp/upload-receipt): Builds the Ramp-specific multipart body with idempotency_key, user_id, optional transaction_id, and the file; internal auth + assertToolFileAccess guard the endpoint before the Ramp call.
• Block & tools: The block cleanly maps 25 operations to conditional sub-blocks, correctly converts pageSize/amounts to numbers, and normalises the file input. All read tools follow the shared buildRampUrl + buildRampHeaders + extractRampError utilities, and list tools use the extractNextStart cursor helper.

Confidence Score: 4/5

The integration is well-structured and the receipt upload route is properly guarded by internal auth and file-access checks; the two findings are both hardening suggestions with no realistic attack surface today.

The implementation follows the established patterns for OAuth providers, block definitions, and tool utilities consistently across 46 files. The only actionable findings are a missing CRLF strip on multipart field values (inconsistent with the filename sanitization already present) and generic scope-description keys that could silently collide with future provider registrations. Neither represents a current breakage.

apps/sim/app/api/tools/ramp/upload-receipt/route.ts (multipart field sanitization) and apps/sim/lib/oauth/utils.ts (generic scope key names)

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant User as User / Workflow
    participant Block as Ramp Block
    participant ToolExecutor as Tool Executor
    participant InternalRoute as /api/tools/ramp/upload-receipt
    participant Storage as File Storage
    participant RampAPI as Ramp API

    User->>Block: configure operation + inputs
    Block->>ToolExecutor: resolve tool (e.g. ramp_list_transactions)

    alt Read / list / create tool
        ToolExecutor->>RampAPI: GET/POST https://api.ramp.com/developer/v1/...
        RampAPI-->>ToolExecutor: JSON response
        ToolExecutor-->>Block: transformed output
    end

    alt Upload Receipt
        ToolExecutor->>InternalRoute: POST /api/tools/ramp/upload-receipt
        InternalRoute->>InternalRoute: checkInternalAuth + parseRequest
        InternalRoute->>InternalRoute: processFilesToUserFiles + assertToolFileAccess
        InternalRoute->>Storage: downloadFileFromStorage
        Storage-->>InternalRoute: file buffer
        InternalRoute->>InternalRoute: buildReceiptMultipartBody
        InternalRoute->>RampAPI: POST /developer/v1/receipts (multipart/form-data)
        RampAPI-->>InternalRoute: "{ id: receiptId }"
        InternalRoute-->>ToolExecutor: "{ success: true, output: { receiptId } }"
        ToolExecutor-->>Block: receiptId
    end

    alt OAuth Token Refresh
        ToolExecutor->>RampAPI: POST /developer/v1/token (Basic auth)
        RampAPI-->>ToolExecutor: new access_token + refresh_token
    end

_{Reviews (2): Last reviewed commit: "feat(integrations): add Ramp integration..." | Re-trigger Greptile}

@greptile

@cursor review