Quickstart

You need a tenant secret key beginning with tnk_. Store it in your secret manager and expose it only to trusted backend services.

export FIDERA_API_KEY="tnk_..."

1. Create a Check

This example screens a customer and transaction receiver in one immutable Check. external_id links or creates the Applicant using your stable customer identifier. reference_id links the Check to your payment.

curl https://api.fideralabs.com/v1/checks \
  --request POST \
  --header "Authorization: Bearer $FIDERA_API_KEY" \
  --header "Idempotency-Key: payment-9842-screen-v1" \
  --header "Content-Type: application/json" \
  --data '{
    "type": "aml_screen",
    "use_case": "transaction",
    "mode": "sync",
    "reference_id": "payment-9842",
    "applicant": {
      "external_id": "customer-481",
      "legal_name_first": "Jane",
      "legal_name_last": "Example"
    },
    "datasets": ["sanctions", "pep", "crypto_wallets"],
    "subjects": [
      {
        "reference_id": "customer-481",
        "type": "person",
        "role": "sender",
        "name": "Jane Example",
        "date_of_birth": "1990-01-01",
        "nationality": "US"
      },
      {
        "reference_id": "party-receiver",
        "type": "company",
        "role": "receiver",
        "name": "Example Trading Ltd",
        "country": "GB",
        "registration_number": "01234567"
      }
    ]
  }'

Persist these response fields:

• id — the immutable Fidera Check ID;
• applicant_id — the Fidera Applicant that owns the Check;
• input_ref — the normalized reconciliation reference;
• decision — clear, review, hold, or error;
• alert_count — actionable Alerts emitted from the Check.

For a transaction, an actionable hit produces hold. Required screening data being unavailable does not produce clear.

2. Read the Check

Async Checks return before evaluation finishes. Poll the Check until its status is terminal, or react to the corresponding webhook.

curl "https://api.fideralabs.com/v1/checks/$CHECK_ID" \
  --header "Authorization: Bearer $FIDERA_API_KEY"

The response preserves normalized queries, source and dataset versions, policy version and snapshot, match explanations, timings, and related Alert counts.

Request the same Check as Markdown by changing the representation header, not the resource URL:

curl "https://api.fideralabs.com/v1/checks/$CHECK_ID" \
  --header "Authorization: Bearer $FIDERA_API_KEY" \
  --header "Accept: text/markdown"

JSON remains the default and is explicit with Accept: application/json. Responses include Vary: Accept. In the Fidera dashboard origin, /checks/{check_id}.json and /checks/{check_id}.md are convenience URLs that translate their suffix into the same API request; .md is not a separate public API endpoint.

3. Read actionable Alerts

Filter Alerts to the Check that produced them:

curl "https://api.fideralabs.com/v1/alerts?check=$CHECK_ID" \
  --header "Authorization: Bearer $FIDERA_API_KEY"

An Alert is the work item for a match. Your internal case should store the Fidera alert_id and check_id; Fidera does not create or own the case.

4. Export evidence

Export the immutable Check evidence in the format your control or examiner workflow needs.

curl "https://api.fideralabs.com/v1/checks/$CHECK_ID/export?format=pdf" \
  --header "Authorization: Bearer $FIDERA_API_KEY" \
  --output check-evidence.pdf

JSON, CSV, Markdown, and PDF are supported. The Check resource itself remains the source of truth.

Next steps

• Model Applicants, Checks, and Alerts.
• Add idempotency and cursor pagination.
• Receive signed webhook events.
• Build an operator workflow for Alert review.