/api/v1/scrapping/sandboxScrapping sandbox endpoint.
Scrapping sandbox endpoint. Used for development + integration testing of the scrapping pipeline. Returns synthetic but schema-correct payloads.
10 tokensSince v1.0.0
Why use this
Verify your API key, the rate-limit headers, and your token-debit ledger end-to-end without consuming production data — call this once on integration day to confirm everything wires up. Returns a deterministic synthetic payload that's schema-identical to what real scrapping endpoints return (same auth headers, same cost-debit semantics, same `request_id` shape). Cost is intentionally non-zero (10 tokens) so the debit shows up in your `/account/transactions` ledger and validates your billing wiring before you run heavier real calls. Idempotent — every call returns the same payload (modulo `request_id`, `as_of`, and `remaining_balance`).
Sandbox endpoint that returns a deterministic test response — useful for verifying API key auth, rate-limit headers, and your token-debit ledger without consuming production data. Always returns the same payload; idempotent. Cost is intentionally non-zero (10 tokens) so customers can see how token-debiting flows end-to-end before integrating against real endpoints.
Response schema
| Field | Type | Nullable | Description |
|---|---|---|---|
| message | string | no | Always the literal string `"sandbox response"` — useful as a smoke-test assertion in CI pipelines (`assert resp.json()['message'] == 'sandbox response'`). |
| request_id | string | no | Per-call UUID generated server-side. Surface this in support tickets when integration debugging — operations can grep this directly out of nginx + main_api logs to trace the exact request lifecycle (gateway routing, auth resolution, token debit, response). |
| auth_method | string | no | How the gateway authenticated the request: `api_key` (X-API-Key header), `jwt` (Authorization Bearer), or `session` (cookie-based, internal-only). Most production integrations should see `api_key` — anything else may indicate auth-header mis-wiring. |
| cost_debited | integer | no | Tokens debited from your balance for this call. Always 10 on the sandbox endpoint. Echoes the `X-Tokens-Charged` response header — useful for asserting your billing-ledger client correctly mirrors the server-side debit. |
| remaining_balance | integer | no | Token balance remaining on the account AFTER this debit (i.e. `balance_before - cost_debited`). Use to assert your local balance cache stays in sync with the server-side ledger. When this approaches zero, expect 402 Payment Required on subsequent calls. |
| as_of | string | no | ISO-8601 UTC timestamp the response was generated server-side (NOT cached — always reflects request time, since this endpoint is uncached so callers can verify rate-limit + debit semantics on every call). |
Sample response
·
- "message": "sandbox response"
- "request_id": "a1b2c3d4-..."
- "auth_method": "api_key"
- "cost_debited": 10
- "remaining_balance": 198432
- "as_of": "2026-05-01T20:55:12.000Z"
Errors
| Status | Label | Description |
|---|---|---|
| 200 | OK | Request succeeded. |
| 400 | Bad Request | Invalid query, body, or path parameter. |
| 401 | Unauthorized | Missing or invalid Authorization header / api_Token. |
| 402 | Payment Required | Insufficient token balance for this call. Top up |
| 429 | Too Many Requests | Rate limit exceeded for your tier (see /pricing for tier limits). Tier limits |
| 500 | Server Error | Unexpected server-side failure. Retry with backoff; report if persistent. |
Code samples
curl "https://api.finradar.ai/api/v1/scrapping/sandbox?api_Token=YOUR_API_KEY" \
-H "Authorization: Bearer YOUR_JWT_TOKEN"Generate an API key in /account/credentials to run live queries (literal YOUR_API_KEY placeholder shown until then).