generated: '2026-08-26'
method: searched
source: >-
  https://api-docs.nav.com/docs/rest-api/guides/base-url +
  https://api-docs.nav.com/docs/widgets/getting-started +
  https://api-docs.nav.com/docs/widgets/reference/custom-element
checked: '2026-08-26'
summary: >-
  Nav publishes a full, separately-hosted sandbox environment covering BOTH surfaces — the REST API
  and the embedded widget — and states it behaves identically to production without real
  side-effects. What it does NOT publish is any test data: no test EINs, no seeded businesses with
  known bureau files, no magic account ids, no fixture triggers and no time simulation. A partner
  can exercise the request/response contract in sandbox but cannot rehearse a specific
  credit-visibility outcome.
available: true
self_serve: false
access_note: >-
  Sandbox access still requires a partner API key issued by Nav during onboarding. There is no
  anonymous or self-signup sandbox, so this pipeline could not exercise it.
environments:
- name: production
  api_base_url: https://api.nav.com
  widget_base_url: https://app.nav.com
  sso_token_endpoint: https://api.nav.com/v1/sso-token
- name: sandbox
  api_base_url: https://api.sandbox.nav.com
  widget_base_url: https://app.sandbox.nav.com
  sso_token_endpoint: https://api.sandbox.nav.com/v1/sso-token
  statement: >-
    "Use the sandbox environment for development and testing. The sandbox behaves identically to
    production but does not create real accounts or trigger real downstream effects."
  widget_guidance: >-
    "Your origin must be registered before you go to production. Use the sandbox environment for all
    development."
environment_selection:
  mechanism: base URL
  by_credential: false
  key_prefix_convention: none published
  note: >-
    Unlike providers that prefix test credentials (sk_test_ / lp_ / hp_live_), Nav distinguishes
    environments only by host. A key cannot be identified as sandbox or production by inspection,
    and neither can a request that has the wrong base URL hard-coded. That is a real footgun for an
    agent assembling calls from documentation.
test_data:
  test_cards: none published
  test_bank_accounts: none published
  test_identifiers: none published
  seeded_fixtures: none published
  trigger_values: none published
  note: >-
    No published mechanism to force a particular CreditqualsVisibilityStage (new_business /
    foundation_ready / partial_visibility / full_visibility) or a particular ActivationStatus in
    sandbox. The example values that appear in the docs (acct_kEbVRwd8Dz, biz_kEbVRwd8Dz,
    12-3456789, 700123456, EFX123456, 123456789, "Acme Corporation") are illustrative request/response
    samples, NOT documented sandbox fixtures, and are recorded here only so a later pass does not
    mistake them for test data.
time_simulation:
  supported: false
  note: >-
    No test clocks. Relevant because Nav's own semantics are time-bound — 2-minute SSO token expiry,
    a 24-hour Idempotency-Key retention window, monthly bureau tradeline reporting — and none of
    them can be fast-forwarded.
request_shape_rehearsal:
  supported: true
  mechanism: 'X-Strict-Validation: true'
  note: >-
    The closest thing Nav offers to a dry run. Sending the header makes the API reject any request
    carrying fields not in the schema and name them in the response, which is how a client written
    against prose documentation can verify its body shape. See conventions/nav-conventions.yml.