Continuous checks

How it works

A continuous check keeps watching a subject after the first report. You enroll the subject with the same name, date of birth, aliases, address history, purpose and searches as an order, plus an evergreen authorization. We take a baseline at once, then re-evaluate on the interval you set (30 days by default). An evaluation searches the stored data and runs the identity, jurisdiction and dispute controls with no live work; a candidate record that was not in the baseline is a change, and a change places an order with source: "continuous" — the order then does the live re-verification, the evidence, the report and the receipt exactly as any other. Nothing is reported from the evaluation itself, and a record that disappears from the baseline is noted, never reported.

• Enrollment and evaluations are free; only the order a change places is billed ($4.95, or your custom price). Each evaluation records a fcra_monitor_evaluation usage event for reference.
• monitor.change_found carries the monitor and the order; order.created and the rest follow as usual.
• Adverse action started on an order the monitor placed deactivates the monitor (inactiveReason: "adverse_action"): re-enroll after the decision if the relationship continues.
• An evergreen authorization is required. A one-time authorization for a single report does not cover ongoing checks; collect it in your own flow or ask us about adding it to the hosted flow.
• An order a continuous check places runs with liveScope: "relevant".
• A continuous check with a healthcare search follows the lists: every day we check whether any healthcare source’s file was refreshed (the HHS-OIG list is replaced by the 10th of each month), and evaluate when one was and at least seven days have passed since the last evaluation, or when the interval is up. A list entry matched on the name alone is never a change.

Enroll a subject

curl -X POST "https://api.offendersearch.app/v1/fcra/monitors" \
  -H "X-API-Key: $OFFENDERSEARCH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "endUserId": "eu_0b44acbeefeaa7d7",
    "permissiblePurpose": "employment",
    "consent": { "obtainedAt": "2026-10-20T10:00:00Z", "method": "esign", "evergreen": true },
    "subject": { "firstName": "Jordan", "lastName": "Rivera", "dob": "1988-04-12",
                 "addresses": [{ "state": "OH", "city": "Columbus", "postalCode": "43215", "from": "2019-01" }] },
    "searches": [{ "type": "sex_offender" }, { "type": "criminal" }],
    "useLocation": { "state": "OH", "city": "Columbus" },
    "intervalDays": 30,
    "clientReference": "emp-2041"
  }'

The EvergreenConsent object

The consumer's authorization to be checked on an ongoing basis. A one-time authorization does not cover a continuous check: evergreen must be true.

Returned or accepted by POST /v1/fcra/monitors, GET /v1/fcra/monitors, GET /v1/fcra/monitors/{monitor_id}, DELETE /v1/fcra/monitors/{monitor_id}, POST /v1/fcra/monitors/{monitor_id}/evaluate.

The Monitor object — a continuous check

A subject enrolled in a continuous check: its baseline, when it was last evaluated and will be next, and the orders it placed.

Returned or accepted by POST /v1/fcra/monitors, GET /v1/fcra/monitors, GET /v1/fcra/monitors/{monitor_id}, DELETE /v1/fcra/monitors/{monitor_id}, POST /v1/fcra/monitors/{monitor_id}/evaluate.

Evaluate, unenroll

Evaluations run on the schedule; POST /v1/fcra/monitors/{id}/evaluate runs one now and moves the next out by the interval. DELETE /v1/fcra/monitors/{id} unenrolls; orders already placed stay. The monitor object shows the baseline’s candidate count, the number of evaluations and orders, and the last change.

Test FCRA orders on the sandbox server

With a test key (os_test_…) every account is a sandbox FCRA partner on the sandbox server, with the same last-name rules. Register an end user, then place orders against it; nothing is billed. An order finishes right after the 202: read it once with GET /v1/fcra/orders/{orderId}.

Base URL

https://sandbox.offendersearch.app Not https://api.offendersearch.app, which takes live keys only.

Test key

In the dashboard, Developers → API keys → Create test key. Test keys begin os_test_; send yours in the X-API-Key header.

curl -X POST "https://sandbox.offendersearch.app/v1/fcra/end-users" \
  -H "X-API-Key: $OFFENDERSEARCH_TEST_KEY" \
  -H "Content-Type: application/json" \
  -d '{
      "name": "Sample Staffing LLC",
      "permissiblePurposes": [
        "employment"
      ],
      "certification": {
        "text": "End user certifies it will use reports only for employment purposes.",
        "version": "v1",
        "certifiedAt": "2026-10-01T12:00:00Z"
      }
    }'

curl -X POST "https://sandbox.offendersearch.app/v1/fcra/orders" \
  -H "X-API-Key: $OFFENDERSEARCH_TEST_KEY" \
  -H "Content-Type: application/json" \
  -d '{
      "endUserId": "{endUserId}",
      "permissiblePurpose": "employment",
      "consent": {
        "obtainedAt": "2026-10-01T12:00:00Z",
        "method": "esign"
      },
      "subject": {
        "firstName": "Pat",
        "lastName": "Records",
        "dob": "1980-01-01"
      },
      "searches": [
        {
          "type": "sex_offender"
        },
        {
          "type": "criminal"
        }
      ]
    }'

Try it here

Pick a scenario, edit the request, and run it against the sandbox from this page. The explorer accepts os_test_ keys only and never reaches the live host, so nothing here is billed; the “production” code it copies is for your own backend with a live key.

curl -X POST https://sandbox.offendersearch.app/v1/fcra/end-users \
  -H "X-API-Key: $OFFENDERSEARCH_TEST_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Sample Staffing LLC", "permissiblePurposes": [ "employment" ], "certification": { "text": "End user certifies it will use reports only for employment purposes.", "version": "v1", "certifiedAt": "2026-10-01T12:00:00Z" } }'

Every test name: FCRA API sandbox orders·Postman collection·FCRA API sandbox