Apify

The whole Apify v2 REST API behind one wildcard route
View as Markdown

Proxies the entire Apify v2 REST API — run actors (including the run-sync variants that return results inline), tasks, runs, datasets, key-value stores, and more. Like ElevenLabs, it’s a whole API surface, so the gateway mounts a wildcard and forwards the path after /apify/ verbatim:

GET|POST|PUT|DELETE /apify/<api path> → https://api.apify.com/<api path>

Because the path passes through unchanged, new Apify endpoints work without any gateway change. The methods are Apify’s full REST verb set — GET, POST, PUT, DELETE.

Common paths

PathPurpose
POST /apify/v2/acts/{actorId}/runsRun an actor
POST /apify/v2/acts/{actorId}/run-sync-get-dataset-itemsRun an actor and get results inline
GET /apify/v2/actor-runs/{runId}Run status
GET /apify/v2/datasets/{datasetId}/itemsRead dataset items
GET, PUT, DELETE /apify/v2/key-value-stores/{storeId}/records/{key}Key-value store record

What the gateway injects and strips

Apify accepts its token as either an Authorization: Bearer header or a token query parameter. The gateway forecloses both channels:

  • The Authorization header is overwritten with the secret Apify token (Apify reuses the same header you use for your gateway token). Your gateway token is consumed by the gateway and never reaches Apify.
  • A client-supplied token query param is dropped (in any encoding), so the injected token can’t be overridden.

Examples

$curl -X POST "$GATEWAY/apify/v2/acts/apify~website-content-crawler/run-sync-get-dataset-items" \
> -H "Authorization: Bearer $TOKEN" \
> -H "Content-Type: application/json" \
> -d '{"startUrls": [{"url": "https://example.com"}]}'

The response is Apify’s JSON, returned unchanged. For request and response fields, follow Apify’s API reference — the gateway does not alter them.