Skip to main content
An endpoint wraps a scraper in a stable, typed REST URL. You define the slug, the parameters it accepts and the shape it returns; ManyPI handles caching, validation and the async fallback.
This is the “turn any website into an API” part of ManyPI — the same machinery the sales side runs on, exposed for your own integrations.

​
Creating an endpoint

​
Calling it

The call requires the endpoints:invoke permission on the key. Slugs resolve within the key owner’s endpoints, so your slug namespace is your own.

​
How a call resolves

1

Cache

If freshness is cached_ok and a fresh result exists, it is returned immediately — no crawl credits spent.
2

Synchronous scrape

Otherwise the scrape runs inline, up to a ~110 second budget. Most calls finish here.
3

202 fallback

If it exceeds the budget — or the endpoint is async — you get 202 with a run id. Poll GET /v1/e/{slug}/results/{runId} for the result.
That escalation is why an endpoint stays usable from a browser or a Lambda even when the target site is slow: you never hold a connection open indefinitely, and you never lose the work.

​
Your OpenAPI spec

ManyPI generates a live OpenAPI 3.1 document covering your endpoints:
Feed it to a client generator, an API gateway, or an AI agent that consumes tool specs — the types come from the schemas you defined, so the generated client is correctly typed with no hand-written models.

​
Endpoint limits

The number of endpoints you can publish depends on your plan; creating one past the limit returns 403 with the reason. Everything else — caching, validation, the OpenAPI spec — is the same on every paid tier.