generated: '2026-08-01'
method: searched
source: DataVisor public integration guides and API references page
docs: https://www.datavisor.com/datavisor-api-guide
note: >-
  DataVisor publishes no OpenAPI or Swagger definition anonymously, so this profile could
  not be derived mechanically. It is assembled only from the authentication and transport
  security statements DataVisor makes on its own public integration pages. Exact header
  names, parameter names and token formats are NOT published publicly and are therefore
  not recorded here; they are issued per customer by a DataVisor technical account manager
  and documented in the gated API guide.
summary:
  types:
  - apiKey
  key_material:
  - access key
  - device token
  network_controls:
  - ip-allowlist
  transport:
    protocol: HTTPS
    minimum_tls: TLSv1.2
  oauth2_flows: []
  openid_connect: false
  mutual_tls: false
schemes:
- name: access-key
  type: apiKey
  applies_to:
  - DataVisor dEdge Device Intelligence WebAPI
  in: unpublished
  parameter_name: unpublished
  description: >-
    DataVisor secures dEdge data access with access keys, alongside IP allowlisting,
    white-box encryption and HTTPS. The location (header vs query) and the parameter
    name are not published on any public page.
  evidence:
    url: https://www.datavisor.com/integrations/datavisor-integration-guide-for-device-intelligence
    quote: >-
      "DataVisor also uses access keys, IP whitelisting, white-box encryption and HTTPs
      to further secure data access."
- name: device-token
  type: bearer-like-token
  applies_to:
  - DataVisor dEdge Device Intelligence WebAPI
  description: >-
    The dEdge SDK initializes on device, sends encrypted device information to the dEdge
    server, and receives a device token. That token is the identifier the client then
    presents when querying the dEdge server WebAPI for device signals. DataVisor states it
    runs an internal algorithm to verify tokens so that forged tokens are rejected. This is
    a resource identifier bound to a device rather than a general-purpose API credential.
  evidence:
    url: https://www.datavisor.com/integrations/datavisor-integration-guide-for-device-intelligence
    quote: >-
      "All data is encrypted and sent to dEdge server, which returns a token for that
      device that you can use to query the dEdge server for device-specific information"
      ... "dEdge has an internal algorithm to verify tokens, so that hackers cannot fake
      our tokens."
network_controls:
- control: ip-allowlist
  applies_to:
  - DataVisor dEdge Device Intelligence WebAPI
  evidence: https://www.datavisor.com/integrations/datavisor-integration-guide-for-device-intelligence
transport_security:
  protocol: HTTPS
  minimum_tls: TLSv1.2
  evidence:
    url: https://www.datavisor.com/datavisor-api-guide
    quote: >-
      "The default integration mechanism for all APIs supports real-time, synchronous
      HTTPS-based RESTful calls (secured with TLS v1.2)."
  encryption_at_rest: true
  encryption_at_rest_evidence:
    url: https://www.datavisor.com/integrations/datavisor-integration-guide-for-comprehensive-fraud-solution
    quote: >-
      "We secure data transmission by providing advanced encryption at rest and supporting
      HTTPS for real-time data transfers."
tenancy:
  model: dedicated-per-customer
  evidence:
    url: https://www.datavisor.com/integrations/datavisor-integration-guide-for-comprehensive-fraud-solution
    quote: >-
      "For every client, we implement the detection system to dedicated cloud machines,
      making sure that your data is only visible and accessible to you."
gaps:
- No public authentication reference page; no header/parameter names published.
- No OAuth 2.0, OpenID Connect or mutual TLS surface documented publicly.
- No public self-service credential issuance; keys are provisioned by a technical account manager.