Release identity
SHA-256 of the pack file bytes: 7fb27d9dd9aa4f3427cd4de31da8739618ae9d65f24c58e9d1a0cfa7208270d0
Distributable: digest matches the release manifest. The binary carries a digest-bound manifest of the distributable library; a pack whose bytes differ from its manifest entry — endpoint, tier, allowlist, or credential edited, with provider, version, and review block preserved — fails the digest check, loses distributability, and renders MODIFIED rather than as the shipped reviewed artifact. Review state and artifact status are different facts: the first is a documentation-review declaration, the second is the identity of the exact bytes.
Capabilities (4)
ramp.transactions.read v1.0.0R0
- Action
- read
- Endpoint
GET https://api.ramp.com/developer/v1/transactions- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-ramp-api-token- Data class
- financial
Read card and spend transactions for the account.
ramp.users.read v1.0.0R0
- Action
- read
- Endpoint
GET https://api.ramp.com/developer/v1/users- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-ramp-api-token- Data class
- pii
Read the account's users: names, emails and roles, which are personal data.
ramp.bills.create v1.0.0R3
- Action
- pay
- Endpoint
POST https://api.ramp.com/developer/v1/bills- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-ramp-api-token- Data class
- financial
Create a bill with its nested payment. Ramp documents that bills created via the API skip the draft phase and are auto-approved, entering at Approved, and that the payment nested in the bill is then processed on the bill's payment method and timing — the call initiates a payment workflow whose documented end state is a processed payment, not money moved at request time, and the action is pay at the R3 floor; pay is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). The registered cost ceiling is a budget control on the declared amount: the gateway refuses a declared amount above it and commits the ceiling against the work budget; it does not bound the amount the provider request encodes.
ramp.cards.physical.create v1.0.0R2
- Action
- create
- Endpoint
POST https://api.ramp.com/developer/v1/cards/physical- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-ramp-api-token- Data class
- financial
Issue a physical card. Issuance creates spending power rather than moving money, and a card can be suspended or terminated, so the action is create at R2, the verb's floor — a lower bound, not a proof that issuance is reversible. Review the spend limits the integration may request: the limit is set at the provider, not in this pack. Virtual-card issuance goes through the funds API, which this pack deliberately does not register.
Credential reference
The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.
- Reference
secret-ref-ramp-api-token- Custody
- customer_vault
- Injection
- header (Authorization)
An OAuth2 access token for the Ramp developer API, minted from the client's own Ramp API client and held in the client's own secret manager. The stored material must be the complete Authorization header value (scheme included). Access tokens expire: either store the client credentials and let the deployment mint tokens, or review the refresh path before enabling. The OAuth scopes are chosen at Ramp, and the minimum that makes these capabilities work is the right set.
Resources
ramp-account(api, financial):https://api.ramp.com/developer/v1
Pack notes and exclusions
Use a Ramp API client whose OAuth scopes cover only what these capabilities need; the pack does not create one. POST /bills creates an approved bill with the payment nested in the same request — Ramp documents that bills created via the API skip the draft phase and are auto-approved, and that the payment is then processed on the bill's payment method and timing — so the call initiates a payment workflow whose documented end state is a processed payment, and it carries the pay action at the R3 floor; pay is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer); the registered cost ceiling and a policy budget are the second control. Card issuance is registered as create at R2, the create verb's floor — a lower bound, not a risk assessment: the card is spending power and the reviewer should confirm the spend limits the integration is allowed to request. The Ramp developer API is narrower than the Ramp dashboard, and this pack registers only what the API actually exposes: as of the OpenAPI export retrieved 2026-09-21 there is no reimbursement-creation endpoint (reimbursements are read-only over the API, with only mileage and receipt-upload POSTs) and no general card-creation endpoint (virtual cards are issued through funds; the card-vault POST requires separate Vault API access), so the pack registers neither — a documented, dated exclusion, not an approximated capability. The pack says nothing about approvals, accounting sync or spend-program management, which the public API does not expose the same way. AAES has not been certified by Ramp; the endpoints here are a reviewable default, not a vendor guarantee.
Review record
Review completed: 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)
- https://docs.ramp.com/openapi/developer-api.json (retrieved 2026-09-21)
- https://docs.ramp.com/developer-api/v1/authorization (retrieved 2026-09-21)
- https://docs.ramp.com/developer-api/v1/bill-pay (retrieved 2026-09-21)
- https://support.ramp.com/accessing-the-developer-api (retrieved 2026-09-20)
A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.