Article summary
- A coding agent needs three things to use the Vamo API: the Vamo skills, a safely stored API key and the published spec.
- The Vamo API spec is public, needs no key, and is the source of truth for what the API accepts.
- An agent that calls Vamo endpoints that do not exist is working from memory, and should read the published spec again.
- Ask a coding agent to check Vamo access with one small read-only call before any larger run.
- A Vamo API key cannot reach projects, outreach, members or billing, whatever the agent is asked to do.
Give a coding agent three things: the Vamo skills, a safely stored API key and the published spec. Then ask it to check access with one small read-only call before it does anything larger. The API access skill carries the checks and the rules for failures, so you do not have to write those yourself.
When to use this
This route suits work you want to repeat: a script, a recurring search, a hand-off to another system. A developer or a coding agent calls the Vamo API directly with a key.
If you only want to ask questions in a chat, connecting an AI tool is less work. Choose how to connect compares the routes.
What to hand the agent
The skills. Skills are instructions an agent reads. They teach it how to reach the API, store access, check the connection and read an error. Browse them in the skills catalog. The skills install page has the current steps for each tool. In the app they are listed at Set up > Skills.
A key, stored safely. Create one at Set up > API keys. It is shown once. Give it only the permissions the work needs. Keep it in one private place the agent can read by itself in every session. Keep it out of chat messages and shared files. The API access skill walks through where that place is for your setup.
The published spec. The API describes itself in one public document, and reading it needs no key. It is the source of truth for every operation, parameter and response field. The API reference covers the same ground for a person.
What to ask of it
Four habits keep a coding agent useful and its mistakes small.
- Check access first. One small read-only call proves the key works before anything else runs. The API can also report the account, the plan and the key's permissions.
- Prefer small, filtered requests. Ask for the number of people you want. Ask for more only when the first page is good.
- Report failures plainly. The agent should say which call failed and what the error said. It should not quietly switch to another data source.
- Show one small example before a large run. You see the shape of the result while a mistake is still small.
The API access skill carries the access checks and the rules for failures, and it stays current. To ask for all four in your own words, this is enough:
Read the Vamo API access skill and the published API spec. Check access with one small read-only call. Use small, filtered requests. Tell me plainly when a call fails. Show me one small example before any large run.
If the agent calls endpoints that do not exist
The agent is working from memory, not from the spec. Ask it to read the published spec and use only the operations listed there. When an example and the spec disagree, the spec wins.
A request the API does not recognize comes back as an error with a code. API errors explains each one.
If the agent forgets how to use the API partway through
In a long task an agent can lose track of what it read at the start. Installed skills fix this, because the agent can read them again at any point. Ask it to read the API access skill again, then the part of the spec it needs for the next step.
Starting each new task by reading the spec is a good habit to ask for.
What a key cannot do
A key can hold permissions for search, deep search, deep research, fit rank, lists and contacts. It cannot reach projects, outreach, members, billing or key management. Those stay in the Vamo app, whatever the agent is asked to do.
What to do next
- Set up your agent with Vamo skills covers the skills, the key and network access.
- Keep agent usage in check covers an agent that asks for more than it needs.
FAQs
Why does my agent call Vamo endpoints that do not exist?
The agent is guessing from memory. Ask it to read the published Vamo API spec and to use only the operations listed there.
Why does my agent forget how to use the Vamo API partway through a task?
In a long task an agent can lose track of what it read at the start. Install the Vamo skills and ask the agent to read the API access skill and the spec again.
Still stuck? Tell us.