Sandbox

A test key runs in the sandbox. Your requests go through the same gateway as with a live key: the key, scopes, rate limits, Idempotency-Key, request checks, jobs, files and webhooks all work as in production. Only the work itself is simulated: no tool runs, nothing is created and nothing is charged.

Get a test key

In the cabinet open API → Keys, choose the key type Test and create the key. A test key starts with gsk_test. Use it exactly like a live key.

Every sandbox answer carries the header Grem-Sandbox: true, so a test log is never mistaken for real work - answers made before the key is checked (malformed JSON, 413, unknown path) included.

What happens

• Request checks are real. A request production would refuse is refused in the sandbox with the same status and reason: a missing field, fewer than 4 photos in a content pack, texts with neither a listing, a description, a city nor an area. Form fields of multipart requests, report fields of another category and the house heatingType values are checked too, and so are uploaded files: their type and size. What production cuts or replaces (a long text, an unknown video length) the sandbox accepts too.
• Results are samples. Synchronous tools answer at once with fixed sample values. Async tools return a jobId; the job goes pending → running → its outcome in about 5 seconds.
• The appraisal review stops in action_required with sample extracted data, like in production; confirm it with POST /valuation/review/jobs/{id}/confirm.
• Files are placeholders. PDFs and images are real files you can open; video, docx and texts are short labelled placeholders with the right content type. A file exists only for a finished sandbox job, at that tool's own path and with an artifact id the job returned - otherwise 404. An avatar video is served for any artifact id of a finished job, as in production. Range works (206, 416).
• Webhooks are real. A test key creates and manages sandbox webhook endpoints only. They receive only sandbox job events - signed deliveries with retries, exactly as in production. Live endpoints never receive sandbox events, and a test key cannot see or change them.

Choose the outcome

The Grem-Simulate header picks what the call or job ends with:

The value is case-insensitive. An unknown value answers 400, so a typo never passes as success. Live keys ignore the header.

curl -X POST https://developers.grem.capital/api/v1/text/generate \
  -H "Authorization: Bearer gsk_test_xxx" \
  -H "Content-Type: application/json" \
  -H "Grem-Simulate: failed" \
  -d '{"city":"Berlin","totalArea":64}'

What a test key can do

Differences from production

• Results are fixed samples, not a valuation or real texts. Do not show them to your users.
• The sandbox does not check that the listing in objectId exists or is yours; production answers 403 or 404 in that case.
• Jobs and results are kept for a day.

Related

• Quickstart
• Jobs and results
• Webhooks