Skip to main content
Ask what a user already has before you send them anywhere. A user with a card on file goes straight to a purchase; only a user with an empty vault needs a vault session.
$ORG_TOKEN must be a client-credentials access token. An API key is refused with 400 client_credentials_required.

Read the response

Display fields only, newest card first. The response never includes a card number, and never anything that could decrypt one. An empty data array means the user has a vault and nothing in it. A 404 means the user is not yours yet, and carries no data at all, so check the status before you read the body:
Tell the user which card you are about to use: “your Visa ending 4832”. They approve every purchase anyway, and naming the card is what turns the approval into a yes or no instead of a question.

Handle a user you don’t know

A user id your company has never enrolled is not an empty vault. It is a 404, because there is no user of yours to read:
In the Vault, enrollment is a vault session, not a connect call: create one and send the user its link. Treat connection_not_found and an empty data array as the same next step.

Keep the modes apart

A sandbox token reads sandbox users, and a production token reads production users. A production user_id asked for with sandbox credentials is a connection_not_found 404, not an empty vault, and the message names the mode you asked in.

Learn when a card lands

Point a webhook endpoint at your server and Agentcard tells you when a card lands through a link you minted. vault.card_stored reports the cards Agentcard can attribute to you, not every card the user owns. A user who signs in to the Vault on their own and adds a card, or who adds one after your link’s window closed, stores it successfully and sends you no event. So treat the webhook as a prompt, and the read above as the answer: check the vault when you are about to act for a user, rather than trusting a tally you kept from events.