This page describes AAES Govern’s controls. AAES Operate has private-work permissions, operational reviews and recorded-spend limits; it does not include Govern. About AAES Govern
Before you enable this package
Budgets apply to the amount declared in the task, not to the amount the provider actually sends or moves. Card issuance creates spending power; the reviewer should confirm the spend limits the integration may request, which are set at the provider.
Read each action's effects and exclusions below. Before installation, also read the complete package requirements, including credential issuance, scope, expiry, and provider permissions. These are deployment prerequisites, not capabilities this package supplies.
Capabilities (4)
Each capability below is one registered operation. The complete package JSON includes its exact network destination allowlist. The repository stores it at packs/ramp.json and embeds a copy in the release binary.
Risk tiers. R0 is the minimum for reads. R2 is the minimum for write, create, update, execute, and invoke. R3 is the minimum for delete, send, pay, deploy, approve, share, and transfer. Operators can raise these levels. A minimum tier does not measure the operation's business or confidentiality risk.
On supported execution paths routed through AAES Govern, the R3 actions listed below require approval by an authorized person. Bypass paths and observation-only registrations are outside that guarantee. A provider's restoration feature does not remove this approval requirement. A provider-side approval, such as approving a GitLab merge request, is also separate from AAES Govern human approval. The capability matrix shows which execution paths are implemented, restricted to lab use, or refused at startup. Live compatibility must be tested in your environment.
Field guide. Endpoint is the service address and request method. Connector is the adapter that makes the call. Custody describes how the credential is held; the credential reference identifies the value to resolve. Data class sets handling requirements: pii means personal data, financial means financial records, and internal means internal organizational data.
ramp.transactions.read v1.0.0R0
- Kind
- tool
- 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 transactions.
Read card and spend transactions for the account.
ramp.users.read v1.0.0R0
- Kind
- tool
- 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 users.
Read the account's users: names, emails and roles, which are personal data.
ramp.bills.create v1.0.0R3
- Kind
- tool
- 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 bills.
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 minimum R3 tier; pay is one of the designated actions requiring human approval.
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
- Kind
- tool
- 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
Create physical cards.
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 minimum tier; it does not establish 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 credential field names a reference rather than containing credential material. Packs are designed not to contain secrets; the format checks cover only known credential formats and cannot prove that arbitrary text contains no secrets. Installing a package registers its capabilities. Configure the provider credentials, endpoints, and network access, then test the integration in your environment before enabling it.
- Reference
secret-ref-ramp-api-token- Custody
- customer_vault
- Injection
- header (Authorization)
Configure the value and injection format specified in the package. Assign responsibility for credential rotation and revocation, restrict provider permissions, and keep credential material out of logs and responses.
Complete credential requirements
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
Technical package and review record
Complete provider requirements 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 minimum R3 tier; pay is one of the designated actions requiring human approval; the registered cost ceiling and a policy budget are the second control.
Card issuance is registered as create at R2, the create action's minimum tier — 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 configuration to review and test; the vendor has not endorsed it.
Download the complete package JSON for exact network allowlists, credential requirements, exclusions, and setup notes. Read these requirements before installation.
The full documentation review record is supplied in the evaluation package. The evaluation package runs in your environment and comes only with the paid design partnership. This page reproduces the source links and review block; the full record is available for evaluation. Discuss a design partnership to inspect it before installation.
Review block
This section reproduces the review block recorded in the pack file. The evidence and approval record is separate: for a reviewed pack, it is in the evaluation materials and in the release binary's embedded assets.
Review completed: 2026-09-23
7 sources, retrieved 2026-09-20, 2026-09-21, 2026-09-23
- 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)
- https://docs.ramp.com/llms-guides/authorization.txt (retrieved 2026-09-23)
- https://docs.ramp.com/llms-guides/bill-pay.txt (retrieved 2026-09-23)
- https://docs.ramp.com/llms-guides/bill-payments.txt (retrieved 2026-09-23)
Current documentation links are navigation aids. They do not change the package, its historical sources or its review date. Review dates describe a documentation review, not a live integration test. No package is provider-endorsed or yet tested against a live provider tenant.
Release identity
SHA-256 of the pack file bytes: 28d0fc9a7997294510611c1c778dc292534480b6977311b3ec29f6a9f5cd9a3d
Distributable: yes, digest matches the release manifest. Editing a package changes its release identity. A deployment plan checks its own file digests; it does not restore reviewed status or authenticate approval.