> ## Documentation Index
> Fetch the complete documentation index at: https://docs.herondata.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Download a subject's background check as XML

> Returns the requested subject's background check as machine-readable XML, base64-encoded in a JSON payload.

The document is rooted at `<background_check>` carrying `end_user_id`, `end_user_name`, `status`, `subject_key` and a UTC `generated_at`. Under it: `<outcome>` with the deal's result, severity and check counts; `<policy_checks count="n">` of `<check>`; and `<subjects>` holding the one requested `<subject>`. Within the subject, `<application>` is the identity that was searched, and each exported section is an element named for its key (`criminal`, `liens`, `ofac`, ...) carrying `count` and one `<record>` per row. A section's list fields are siblings of those elements rather than nested in them, in the same `count`/`<record>` shape — `phones`, `addresses`, `emails`, `business_profile_details`, `business_contacts` and `work_affiliations` — so `profile` itself has no element, only its lists.

Element and field names are those of `BackgroundCheckResponseSchema`, which is the data dictionary for their meaning. Values are machine-typed rather than display-formatted: a boolean is `true`/`false`, a list is a repeated element, an amount is a bare decimal, and an absent field is omitted rather than empty so a consumer can test for presence. The deal's outcome and policy checks are repeated in every subject's file, so each file stands on its own.

A check's `id` is `<scope>:<signal>`, and the scope is what the check covers rather than necessarily this subject: `owner_1`, `owner_2` and `business` each name one subject, `any_owner` is the worst outcome across the owners, and `submission` is computed over the whole deal. So a subject's file carries checks about the other subjects too, and a failing `any_owner` or `submission` check should not be attributed to the subject whose file it arrived in.




## OpenAPI

````yaml https://app.herondata.io/swagger get /api/end_users/{end_user_heron_id}/background_check/subjects/{subject_key}/raw_report
openapi: 3.0.0
info:
  contact:
    email: support@herondata.io
    name: Support
  title: Heron Data API
  version: '2021-07-19'
servers:
  - description: Production
    url: https://app.herondata.io
security:
  - ApiKeyAuth:
      - key_XXX
externalDocs:
  description: Read Tutorial
  url: https://docs.herondata.io/
paths:
  /api/end_users/{end_user_heron_id}/background_check/subjects/{subject_key}/raw_report:
    get:
      tags:
        - EndUsers
      summary: Download a subject's background check as XML
      description: >
        Returns the requested subject's background check as machine-readable
        XML, base64-encoded in a JSON payload.


        The document is rooted at `<background_check>` carrying `end_user_id`,
        `end_user_name`, `status`, `subject_key` and a UTC `generated_at`. Under
        it: `<outcome>` with the deal's result, severity and check counts;
        `<policy_checks count="n">` of `<check>`; and `<subjects>` holding the
        one requested `<subject>`. Within the subject, `<application>` is the
        identity that was searched, and each exported section is an element
        named for its key (`criminal`, `liens`, `ofac`, ...) carrying `count`
        and one `<record>` per row. A section's list fields are siblings of
        those elements rather than nested in them, in the same
        `count`/`<record>` shape — `phones`, `addresses`, `emails`,
        `business_profile_details`, `business_contacts` and `work_affiliations`
        — so `profile` itself has no element, only its lists.


        Element and field names are those of `BackgroundCheckResponseSchema`,
        which is the data dictionary for their meaning. Values are machine-typed
        rather than display-formatted: a boolean is `true`/`false`, a list is a
        repeated element, an amount is a bare decimal, and an absent field is
        omitted rather than empty so a consumer can test for presence. The
        deal's outcome and policy checks are repeated in every subject's file,
        so each file stands on its own.


        A check's `id` is `<scope>:<signal>`, and the scope is what the check
        covers rather than necessarily this subject: `owner_1`, `owner_2` and
        `business` each name one subject, `any_owner` is the worst outcome
        across the owners, and `submission` is computed over the whole deal. So
        a subject's file carries checks about the other subjects too, and a
        failing `any_owner` or `submission` check should not be attributed to
        the subject whose file it arrived in.
      parameters:
        - description: The Heron ID of the end user
          in: path
          name: end_user_heron_id
          required: true
          schema:
            type: string
        - description: The background check subject to export
          in: path
          name: subject_key
          required: true
          schema:
            enum:
              - owner_1
              - owner_2
              - business
            type: string
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/BackgroundCheckRawReportSchema'
          description: OK
        '404':
          description: >-
            End user not found, or the deal has no completed check for that
            subject
      security:
        - ApiKeyAuth: []
components:
  schemas:
    BackgroundCheckRawReportSchema:
      properties:
        file_b64:
          description: Base64-encoded document bytes
          type: string
        filename:
          description: Suggested download filename
          type: string
        mime_type:
          description: MIME type of the document
          type: string
      required:
        - file_b64
        - filename
        - mime_type
      type: object
  securitySchemes:
    ApiKeyAuth:
      in: header
      name: x-api-key
      type: apiKey

````