Skip to content

Freshservice Sandbox setup

Sujay Singh edited this page Sep 15, 2026 · 1 revision

Test sequence first, then lab wiring. Freshservice API auth is the API key as basic auth username with X as password.

Access tests, in order:

FS_DOMAIN="yoursandbox.freshservice.com"
FS_KEY='paste-key-here'

# 1. Auth works at all
curl -s -u "${FS_KEY}:X" "https://${FS_DOMAIN}/api/v2/assets?per_page=1" | python3 -m json.tool

200 with one asset means auth and read are live. 401 means bad key, 403 means the service account role lacks asset scope.

# 2. Asset types visible, grab the Computer and Laptop type ids for sandbox
curl -s -u "${FS_KEY}:X" "https://${FS_DOMAIN}/api/v2/asset_types?per_page=100" \
  | python3 -c "import sys,json;[print(t['id'],t['name']) for t in json.load(sys.stdin)['asset_types']]"

# 3. A real laptop with full type fields, confirms clone carried the schema
curl -s -u "${FS_KEY}:X" "https://${FS_DOMAIN}/api/v2/assets?include=type_fields&per_page=5" | python3 -m json.tool

# 4. Write permission, harmless field update on one test asset
curl -s -u "${FS_KEY}:X" -X PUT -H "Content-Type: application/json" \
  "https://${FS_DOMAIN}/api/v2/assets/<display_id>" \
  -d '{"description":"sandbox write test"}' | python3 -m json.tool

# 5. Rate limit headers, calibrates pacing
curl -s -D - -o /dev/null -u "${FS_KEY}:X" "https://${FS_DOMAIN}/api/v2/assets?per_page=1" | grep -i ratelimit

Test 3 matters most: confirm the cloned laptops show the Discovery Agent populated fields, serial, UUID, hostname, and note the field key suffixes. Sandbox field keys should match prod for cloned fields, verify one against your prod screenshot, that single check validates the whole id mapping assumption.

Lab setup, once all five pass:

  1. Vault: secret/infra/sandbox/freshservice with api_key, domain. Collector and engine read environment from Vault path selection, nothing hardcoded.
  2. Prod guard into fs_enrich before anything else: target domain matching prod without FS_ALLOW_PROD=true refuses with exit 2. Ten lines, do it first, everything after runs safer.
  3. Create the four MVP fields in sandbox UI under Computer, intune_compliance, intune_last_seen, intune_primary_user, intune_last_checkin. Then re run test 3 and record their generated field keys into the sandbox mapping file. These keys will differ in prod, that remap is already a named deployment step.
  4. Pick 10 lab devices: pull 10 corporate Windows serials from your Intune output, find their cloned assets in sandbox via filter query on serial, note display_ids. That is your matched cohort. Also note 2 Intune serials with no sandbox asset, that is your gap cohort. Fifteen minutes of prep that makes every later test measurable.
  5. Point the snapshot job at sandbox, confirm fs_vmware_assets.json equivalent pulls cloned data cleanly, then run the Intune collector for real and the engine in dry run against the cohort.
  6. Ask the Fresh team one operational question now: resync schedule, and whether your created fields survive resync or get wiped. If resync nukes custom fields, every test window needs planning around it, better to know before building on top.

Exit state for the lab being "set up": five tests green, guard in place, fields created and keyed, cohort documented, dry run producing a match report. From there the guard trip tests and capped live writes follow the sequence we already locked.

Clone this wiki locally