Corporate card and spend-management API for reading transactions, bills, vendors, cards, and reimbursements, and for creating/updating spend programs, limits, and accounting records on a Ramp business.
Corporate card and spend-management API for reading transactions, bills, vendors, cards, and reimbursements, and for creating/updating spend programs, limits, and accounting records on a Ramp business. Best when an agent needs to query or act on a company’s actual card and AP activity. Unlike accounting APIs (QuickBooks, Xero), Ramp is the system of record for the underlying card swipes and bill payments themselves.18 example endpoints available through Lava’s AI Gateway. See the Ramp API docs for full documentation.
This provider requires your own credentials — connect your API key or OAuth account before use.
This is a catch-all provider — any valid URL under https://api.ramp.com/developer/v1 is supported. Any Ramp Developer API endpoint. Construct URL as https://api.ramp.com/developer/v1/{path}. Card lifecycle actions (freeze/unfreeze/terminate) are POSTs to /cards/{card_id}/deferred/{suspension|unsuspension|termination} with a { “idempotency_key”: ”…” } body — each returns a deferred task you poll at GET /cards/deferred/status/{task_id}. PATCH /cards/{card_id} only edits display name, owner, and spending limits; it has NO state field, and a card’s state and spending_restrictions.suspended are read-only (returned by GET, rejected on write). See https://docs.ramp.com/developer-api/v1 for the full reference. The endpoints below are curated examples.
Create an approved bill and select the payment method (ACH, check, wire, SWIFT, or Ramp card) in one call. Bills created via the API skip the draft phase. Resolve vendor_id, vendor_contact_id, entity_id, and source_bank_account_id from the entities/vendors endpoints first.
List vendor credits (credit memos) for the business. Read-only: Ramp exposes vendor credits for reading only — there is NO API to create or upload a vendor credit. Vendor credits are issued in the Ramp UI from a paid bill and synced to accounting.
Edit a card: display name, owner (new_user_id), entity, notification settings, and spending limits. This endpoint does NOT freeze a card — it has no state field, and spending_restrictions.suspended and the card’s state are read-only (returned by GET, rejected on write with DEVELOPER_7001). To freeze, unfreeze, or terminate a card use the deferred actions below; setting spending_restrictions.amount to 0 caps the limit but does not block new charges.
Freeze (suspend) a card — the only way to block new charges. This is NOT a PATCH field and NOT part of spending_restrictions. The action is asynchronous: it returns a deferred task id; poll GET /cards/deferred/status/{task_id} to confirm the card reached the SUSPENDED state. Reverse with the unsuspension endpoint.
Unfreeze (unsuspend) a previously suspended card, restoring it to ACTIVE. Asynchronous — returns a deferred task id; poll GET /cards/deferred/status/{task_id} to confirm.
Permanently terminate a card. This is IRREVERSIBLE — unlike suspension, a terminated card cannot be reactivated. Asynchronous — returns a deferred task id; poll GET /cards/deferred/status/{task_id} to confirm.
Poll the result of a deferred card action. Every card mutation (suspension, unsuspension, termination, and virtual/physical card creation) returns a task id rather than completing inline; fetch this until the task reports success and exposes the resulting card.