Marqeta package v1.0.0

Store the complete Marqeta Core API Authorization header in the client's secret manager: 'Basic <base64(application-token:admin-access-token)>'. The application token is the username and the admin access token is the password. Marqeta lists these keys in its Dashboard; issuance and rotation run outside the agent and executor.

Where available, use Marqeta's self-service credential API (POST /credentials/apikeys/applications/self/accesstokens) to issue an admin access token with only the required roles: read for reads, plus write for card transitions; never pci for this pack. The new token cannot exceed the issuing token's roles. This API is limited release and requires access through a Marqeta representative. Set expires_at explicitly.

Without that access, a Dashboard-issued admin access token carries broad program authority. Treat it accordingly: restrictions then come from the registered capabilities, not from credential scoping.

Role-scoped tokens expire after 90 days by default; expires_at can set 1–365 days. The external process must replace the token and update the vault reference before expiry. Deleting a token sets expiry to seven days after deletion rather than revoking it immediately. Plan emergency cut-off around that residual window.

The agent never receives the value. At execution it is present in executor memory only for injection; the deployment owns memory, log, trace, and crash handling.

The API host varies by environment — Marqeta's Core API Quick Start shows the shared public sandbox host sandbox-api.marqeta.com, and production programs run on dedicated hosts issued by Marqeta — so the registered authority your-program.marqeta.invalid is a placeholder on the reserved .invalid domain, not a reachable host. Replace it with the deployment's actual program host and keep the egress allowlist in step; the allowlist entry is the authority only. USER_TOKEN and ACCOUNT_HOLDER_TOKEN are path placeholders to replace before enabling.

The card read is not enforced metadata-only: Marqeta's card object returns pan by default — the documentation's own sample card response carries a full PAN — the fields query parameter that shapes the response is caller-controlled on this registered GET (left blank it returns all fields), and show_pan and show_cvv_number are caller-settable query parameters on card endpoints; saying those parameters are not registered does not exclude them from a registered route.

Required handling: the deployment must pin response shaping outside the agent's reach (an executor-fixed fields list that excludes pan and cvv_number), treat every response from this capability as potentially PCI-scope cardholder data until that pinning is verified, and keep such responses out of logs, traces and crash reports. The dedicated PAN- and CVV-bearing endpoints (GET /cards/{token}/showpan, POST /cards/getbypan) remain unregistered.

The card-transition capability changes a card's state (for example UNACTIVATED to ACTIVE, or ACTIVE to SUSPENDED): a state transition is a card authorization control — activating enables the card for authorization subject to program configuration, funding and spend controls (not a promise that every transaction up to a limit will be honored), suspending withdraws that eligibility — and it is registered at the pay action's R3 floor under the finance-pack rule that card authorization control sits with money-committing actions, even though no money moves at request time.

This pack does not register card creation (POST /cards issues spending power and is left out until separately reviewed), user or business creation, user transitions, PIN endpoints, funding endpoints (/gpaorders, /fundingsources), program or intra-account transfers, spend-control management (/authcontrols, /velocitycontrols), webhooks, or the /simulate endpoints. AAES has not been certified by Marqeta; the endpoints here are configuration to review and test; the vendor has not endorsed it.