Authentication
How keys work, where to put them, and what happens when one is wrong.
Every request carries your API key in the X-API-Key header. There is no OAuth
flow, no token exchange, and no session to keep alive.
curl -X POST 'https://scrape.crawlzo.com/v1/scrapers/instagram-profile-v4' \
-H 'X-API-Key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"handle": "nasa"}'Base URL and paths
| Part | Value |
|---|---|
| Base URL | https://scrape.crawlzo.com |
| Path prefix | /v1/scrapers/ |
| Full path | https://scrape.crawlzo.com/v1/scrapers/<endpoint> |
| Method | POST with a JSON body, unless the endpoint says otherwise |
| Auth header | X-API-Key: <your key> |
Two endpoints take GET with query parameters instead of a POST body. Both are
in the Google Search section and both say so at the top of their page.
What your key controls
A key identifies your account and determines which endpoints you can call. If
your account has not been enabled for an endpoint, calling it returns 403 with
SCRAPER_NOT_ALLOWED. That is a provisioning question, not a code problem, so
retrying will not help. Ask us to enable it.
When a key is wrong
| Situation | Status | status.code |
|---|---|---|
| Header missing or key not recognised | 401 | UNAUTHORIZED |
| Key valid, endpoint not enabled for you | 403 | SCRAPER_NOT_ALLOWED |
| Endpoint name does not exist | 404 | SCRAPER_NOT_FOUND |
None of these are retryable. Fix the request rather than backing off.
Keeping keys safe
Keys go in your server environment, not in a browser bundle, a mobile app, or a repository. Anything that reaches a user's device is public, whatever the build step does to it.
If a key is exposed, ask us to roll it. Rolling issues a new key and invalidates the old one, so deploy the new value first if you cannot tolerate a gap.
The "Try it" console on this site keeps whatever key you paste in your own browser's local storage. It is sent to the API and nowhere else, and it never reaches this site's server.