AgentRights Node client: explicit retry identity for website-policy checks

Developer Zach Dalphis released a Node.js client for AgentRights, an early-beta paid API that returns source-linked summaries of websites' stated automated-access, scraping and AI-use policies alongside robots.txt checks. The client deliberately separates a policy check from purchasing credits, requiring callers to retain request identity and handle retries manually so an agent does not turn a retry into an unintended new action; Dalphis states the design is not a general guarantee that every server implements idempotency correctly. Dalphis disclosed that sandbox payments are tested but completed real-payment settlement and paid-credit delivery have not been verified end to end, and that the service does not grant permission, provide legal advice, or determine whether scraping is lawful.

I’m building AgentRights, a commercial early-beta API for source-linked summaries of websites’ stated automated-access, scraping and AI-use policies. I’m sharing the client design here because I’d value feedback from people building web-research agents. The service supplies policy context alongside robots.txt checks. It does not grant permission or provide legal advice, and there is no native Hugging Face/smolagents integration yet. The small Node.js client uses an existing bundle and deliberately separates a check from purchasing credits: The tradeoff is less convenience: the caller has to retain request identity and handle recovery explicitly. The client is intended to avoid an agent turning a retry into an unintended new action; it is not a general guarantee that every server implements idempotency correctly. Readable guide: https://agentrights-web.zachdalphis.workers.dev/quickstart.txt https://agentrights-web.zachdalphis.workers.dev/quickstart.txt Client source: https://agentrights-web.zachdalphis.workers.dev/agentrights-check.mjs https://agentrights-web.zachdalphis.workers.dev/agentrights-check.mjs For research-agent builders: would you keep this explicit manual-retry boundary, or put retries in a durable task queue that persists the original inputs and ID? And for the policy output itself, are source excerpts more useful than structured fields or a human-review checkpoint? Disclosure: this is my product and the API is paid. The example uses existing credits only. Sandbox payments are tested, but completed real-payment settlement and paid-credit delivery have not been verified end to end. I am not claiming the service can determine whether scraping is lawful. Thanks for concrete technical feedback.