Agenty
DEVELOPER · DEVELOPER
Scraping agents, jobs, and results run under that account’s own key.
Connecting Agenty in practice
Agenty drives a scraping agent that already exists in the console rather than describing a scrape inline, so every call needs an agent id the API will not give you, and the credential travels as an apikey query parameter. Running one scrape is three calls — load the URLs, start an async job, then poll the job for a paged result — so nothing an agent asks for comes back in the response to the request that asked for it.
Scopes that draw scrutiny
apikey query parameterThe only credential, and Agenty’s own examples put it in the URL rather than a header, so it lands in logs, job records and anything that stores a request URL.
Worth knowing
- The flow is PUT /v1/inputs/{agentId} to load URLs, POST /v1/jobs/scraping/async to start, then GET /v1/jobs/{jobId}/result with offset and limit. The start call returns a job, not data.
- Results are paged by offset and limit, so a large scrape is several fetches after the job completes rather than one.
- Agent ids come from the console. There is no documented call that lists them, so an integration has to be configured with them up front.
- docs.agenty.com is Agenty’s internal staff portal and requires an invite; the public reference lives under agenty.com/docs.
Checked against Agenty API documentation (2026-09-29), Creating an API to scrape website data (2026-09-29)
What an agent can do
Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.
Often connected alongside
Put Agenty behind one governed endpoint.
Same permissions, same audit trail, whatever else you connect next.