Developer documentation

API & SDK reference

Integrate Autogon security into your product. Start with Omniguard for fraud, AML and sanctions screening, then add runtime protection for your apps, APIs, LLMs, edge functions and servers. Every endpoint below is a live REST call with a sample request and response, and each protection layer has a one-line SDK.

Base URL & authentication

All API requests go to a single base URL over HTTPS:

text

https://shield.nemesislabs.xyz/api/v1

Every request is authenticated with a bearer token in the Authorization header. Which token you use depends on what you are calling. You mint each of these once in the console and it is shown only once, so store it as a secret (an environment variable), never in client-side code.

Token	Used for	Where to get it
Omniguard key	Screening, identity, transaction scoring	Console → Omniguard → Knowledge → Reveal API key
App token `nsk_…`	Application / API / LLM Shield ingest	Console → Applications → New app
Developer key `dak_…`	Management API: apps and app mode, plus Omniguard functions, rules, cases and reports	Console → Settings → API keys
Grid token `nsk_grid_…`	Edge / protective-DNS decisions	Console → Network → Protection
Agent key `ashk_…`	Enrolling a server / hosting agent	Console → Fleet, or the server-key API

http

Authorization: Bearer <your-token>

Omniguard

Sanctions & PEP screening

Screen a person or entity name against Nemesis's consolidated watchlist (OFAC, EU, UN and UK sanctions, global PEPs and enforcement lists). Screening is metered but free to start.

POST/api/v1/omniguard/verify

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/omniguard/verify \
  -H "Authorization: Bearer $OMNIGUARD_KEY" \
  -H "Content-Type: application/json" \
  -d '{"check":"sanctions_pep","subject":"John Smith"}'

Response

json

{
  "ok": true,
  "check": "sanctions_pep",
  "subject": "John Smith",
  "provider": "Nemesis Watchlist",
  "status": "flagged",
  "risk": "hit",
  "verdict": "hit",
  "data": {
    "verdict": "hit",
    "sanctionsHit": true,
    "pepHit": false,
    "lists": ["OFAC (US)", "UN"],
    "matches": [
      {
        "caption": "John Smith",
        "schema": "person",
        "score": 0.912,
        "datasets": ["ofac_sdn"],
        "countries": ["US"],
        "sanctioned": true,
        "pep": false
      }
    ]
  },
  "usage": { "used": 5, "limit": 100 }
}

verdict is clear, review or hit. A strong sanctions match returns hit; a weaker name match returns review for manual due diligence.

Identity verification (BVN / NIN / passport)

Verify a national identity number or passport. Set check to bvn, nin or passport, and subject to the number.

POST/api/v1/omniguard/verify

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/omniguard/verify \
  -H "Authorization: Bearer $OMNIGUARD_KEY" \
  -H "Content-Type: application/json" \
  -d '{"check":"bvn","subject":"22212345678","last_name":"Okafor"}'

Response

json

{
  "ok": true,
  "check": "bvn",
  "subject": "22212345678",
  "status": "verified",
  "risk": "clear",
  "verdict": "clear",
  "data": { "verified": true, "detail": "Verified" },
  "usage": { "used": 12, "limit": 100 }
}

Business verification uses check: "kyb". Adverse-media screening uses check: "adverse_media" and returns a list of matched articles under data.hits.

Transaction scoring

Score a transaction against your Omniguard function's rules and models in real time. The response returns a verdict of allow, review or block, with the reasons that drove it. Send any extra fields you have; they are passed to your custom rules.

POST/api/v1/omniguard/score

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/omniguard/score \
  -H "Authorization: Bearer $OMNIGUARD_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "function_id": "b1f2...uuid",
    "amount": 900000,
    "currency": "NGN",
    "channel": "checkout",
    "country": "RU",
    "card_country": "US",
    "device_id": "d-123",
    "ip": "102.89.10.4"
  }'

Response

json

{
  "transaction_id": "9c1e...uuid",
  "rule_score": 72,
  "ai_score": 55,
  "overall_score": 64,
  "verdict": "review",
  "reasons": [
    { "signal": "amount over baseline", "contribution": 30 }
  ],
  "block": false,
  "ctr": { "reportable": false, "threshold": 5000000, "currency": "NGN" },
  "latency_ms": 38
}

Close the loop by reporting the real result to POST /api/v1/omniguard/outcome (fraud, chargeback or legit), which trains the models. Create and manage scoring functions with your dak_ developer key at POST /api/v1/omniguard/functions, and run the rest of the workflow, rules, cases and regulatory reports, from the Omniguard management API below.

Omniguard management API

Everything the Omniguard console does, creating a decision function, tuning its rules, working its cases and filing its regulatory reports, is available as a REST call, so you can build fraud operations into your own back office instead of asking analysts to switch tools. These endpoints authenticate with a developer key (dak_…), not the Omniguard ingest key: the developer key is scoped to exactly one account, is stored only as a hash, and is minted and revoked by an account owner or admin in Console → Settings → API keys.

http

Authorization: Bearer dak_your_developer_key

Every call is bound to that key's account on the server. An id belonging to another tenant returns 404, never someone else's data. Writes are rate limited per account and land in the console's Audit page attributed to Developer API key, so an API change is as traceable as a click.

Decision functions

Start here. A function is one integration unit, a region by app by event combination such as NG / Web / Transfer, and it owns its own rules, its data contract and its two AI models. Everything below hangs off a functionId, so create one first.

POST/api/v1/omniguard/functions

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/omniguard/functions \
  -H "Authorization: Bearer $DEVELOPER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "NG Web Transfer",
    "industry": "fintech",
    "event": "transfer",
    "region": "NG",
    "app": "web"
  }'

Response

json

{
  "functionId": "c7713ef9-5202-4959-9e08-0cdac95f48ab",
  "rulesSeeded": 16,
  "industry": "fintech",
  "event": "transfer",
  "ingestToken": "9b82a87a…",
  "next": "Score transactions: POST /api/v1/omniguard/score with header 'Authorization: Bearer <ingestToken>' …"
}

The function does not start empty. rulesSeeded is the starter rule set matched to your industry and event, already tuned and ready to score, which you then adjust with the rule endpoints below.

The response also hands back your ingestToken. That is the second of the two keys: the developer key you authenticated this call with manages configuration, and the ingest token is what your application servers send transactions with. Keep them separate, since the ingest token is deployed far more widely than the developer key.

Field	Meaning
`name`	Required. How the function appears in the console.
`industry`	Chooses the starter rule set: `fintech`, `banking`, `lending`, `card`, `ecommerce`, `marketplace`, `crypto`, `igaming`, `health`, `insurance`, `energy`, `education`, `general`.
`event`	What the function guards: `transfer`, `login`, `checkout`, `payout`, `registration`, `wallet_funding`, or any custom event name. Default `transfer`.
`region`	Country code or `GLOBAL`. Also decides the regulator on reports (NG files to the NFIU). Default `NG`.
`app`	`web`, `mobile` or `api`. Default `web`.
`threshold`	Transactions to see before the two AI models auto-build. Default 500,000.
`autoCaseThreshold`	Risk score (0 to 100) above which a case is opened automatically. Unset means no auto case.
`alertThreshold`, `alertEmail`	Score at which to email, and who to email.

GET/api/v1/omniguard/functions

Response

json

{
  "count": 1,
  "functions": [
    { "functionId": "c7713ef9…", "name": "NG Web Transfer", "event": "transfer",
      "region": "NG", "app": "web", "threshold": 500000, "createdAt": "2026-09-28T22:08:15Z" }
  ]
}

Rules on a function

A function's rules are what turn a transaction into a score. List them together with the function's data contract, the union of the fields the active rules read, which is exactly what /score needs to be sent for the function to evaluate fully.

GET/api/v1/omniguard/functions/{id}/rules

Response

json

{
  "function": { "functionId": "18afe37b…", "name": "Payouts", "event": "transfer", "region": "NG" },
  "count": 2,
  "dataContract": ["amount", "channel", "customer_ref"],
  "rules": [
    {
      "ruleId": "fe537b96…",
      "name": "Structuring: 950k cash in 24h",
      "type": "sum",
      "weight": 0.95,
      "params": { "field": "customer_ref", "value_field": "amount", "gte": 950000, "window_min": 1440,
                  "filter": { "field": "channel", "value": "cash" } },
      "active": true,
      "requiredFields": ["customer_ref", "amount", "channel"]
    }
  ]
}

Add a rule either from the predefined catalog (pass a templateId) or as your own. weightis the rule's standalone probability of fraud, from 0 to 1. Scores are fused with a noisy-OR, so adding a signal only ever raises risk, and a rule you consider decisive is dialled toward 1.

POST/api/v1/omniguard/functions/{id}/rules

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/omniguard/functions/$FUNCTION_ID/rules \
  -H "Authorization: Bearer $DEVELOPER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Structuring: 950k cash in 24h",
    "type": "sum",
    "weight": 0.95,
    "params": {
      "field": "customer_ref",
      "value_field": "amount",
      "gte": 950000,
      "window_min": 1440,
      "filter": { "field": "channel", "value": "cash" }
    }
  }'

Response

json

{
  "rule": { "ruleId": "fe537b96…", "name": "Structuring: 950k cash in 24h", "type": "sum",
            "weight": 0.95, "active": true,
            "requiredFields": ["customer_ref", "amount", "channel"] },
  "modelsMarkedStale": true
}

modelsMarkedStalemeans the function's AI models were flagged for a retrain: their labels were learned against the old rule set. Scoring is never interrupted by it. Adding the same predefined rule twice returns 409, since a duplicate would double count its weight and quietly inflate every score.

POST/api/v1/omniguard/functions/{id}/rules

Request: from the predefined catalog

shell

# browse the catalog first (optionally filtered by sector)
curl "https://shield.nemesislabs.xyz/api/v1/omniguard/rule-templates?sector=aml" -H "Authorization: Bearer $DEVELOPER_KEY"

curl -X POST https://shield.nemesislabs.xyz/api/v1/omniguard/functions/$FUNCTION_ID/rules \
  -H "Authorization: Bearer $DEVELOPER_KEY" -H "Content-Type: application/json" \
  -d '{"templateId":"9d13e047-f126-412d-abb6-c854ba762887"}'

Rule types

The type decides which engine evaluates the rule, and paramsfollows that type's shape. A type or a parameter set the engine cannot act on is rejected at write time rather than stored as a rule that never fires.

Type	Fires when	params
`amount`	Transaction value crosses a threshold	`{ gte, flag? }`
`geo`	Two location fields disagree	`{ a, b }` (default `country` vs `card_country`)
`compare` / `enrichment`	A field compares true against a value	`{ field, op, value }`, op: gt gte lt lte eq neq
`range`	A field is inside (or outside) a band	`{ field, min?, max?, outside? }`
`velocity`	An identifier recurs too often in a window	`{ field, count, window_min }`
`sum`	Windowed total crosses a threshold (value based structuring)	`{ field, value_field, gte, window_min, filter? }`
`graph`	One identifier is shared across too many distinct entities	`{ field, distinct, threshold, window_min }`
`graph_path` / `graph_ring`	The entity scores high on a multi hop motif (peel chain, cycle, layering, ring)	`{ motif, score }`
`baseline_dev`	Amount sits N sigma above this customer's own norm	`{ z, min_history? }`
`time_anomaly`	The hour is rare for this customer	`{ rarity, min_history?, tz_offset? }`
`ml_gate`	The model score crosses a floor	`{ value }`

External knowledge sources, the rule type that calls your own KYC, KYB or sanctions endpoint during scoring, are attached in Console → Omniguard → Knowledgerather than over this API. That path validates and resolves the host before it is stored, which is what keeps a scoring rule from being pointed at an internal address.

PATCH/api/v1/omniguard/rules/{id}

Request

shell

curl -X PATCH https://shield.nemesislabs.xyz/api/v1/omniguard/rules/$RULE_ID \
  -H "Authorization: Bearer $DEVELOPER_KEY" -H "Content-Type: application/json" \
  -d '{"weight":0.8,"active":false}'

Tunable: weight, active, name. A rule's type and params are not editable in place, because its past firings are attributed to the definition that produced them. Replace the rule instead: delete it, then add the new one.

DELETE/api/v1/omniguard/rules/{id}

Response

json

{ "removed": true, "ruleId": "fe537b96…", "modelsMarkedStale": true }

Case management

A case is the investigation record: a title, a suspect, the transactions that make up the evidence, a priority, an assignee and an SLA. Scoring opens cases for you above your auto case threshold; this API lets your own systems open, triage and close them too.

POST/api/v1/omniguard/cases

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/omniguard/cases \
  -H "Authorization: Bearer $DEVELOPER_KEY" -H "Content-Type: application/json" \
  -d '{
    "title": "Suspected structuring: ACC-88213",
    "suspectRef": "ACC-88213",
    "amountAtRisk": 900000,
    "priority": "high",
    "transactionIds": ["d97f947f-a8af-459e-8f52-49b587babbbd"],
    "slaDays": 3
  }'

Response

json

{
  "case": {
    "caseId": "f5db0c47…",
    "title": "Suspected structuring: ACC-88213",
    "status": "open",
    "priority": "high",
    "assignee": null,
    "amountAtRisk": 900000,
    "suspectRef": "ACC-88213",
    "transactionIds": ["d97f947f…"],
    "slaDue": "2026-10-01T09:14:02.118Z"
  }
}

Every id in transactionIds is checked against your account before it is stored, so a case can never cite evidence you cannot see. Unknown ids come back as 400 unknown_transactions with the offending ids listed.

GET/api/v1/omniguard/cases

Filter with status, priority, assignee and q (title search), page with limit and offset. GET /api/v1/omniguard/cases/{id} returns one case with its transactions and any reports filed against it, plus allowedNextStatuses for the state it is in.

shell

curl "https://shield.nemesislabs.xyz/api/v1/omniguard/cases?status=open&priority=critical&limit=50" \
  -H "Authorization: Bearer $DEVELOPER_KEY"

PATCH/api/v1/omniguard/cases/{id}

Request

shell

curl -X PATCH https://shield.nemesislabs.xyz/api/v1/omniguard/cases/$CASE_ID \
  -H "Authorization: Bearer $DEVELOPER_KEY" -H "Content-Type: application/json" \
  -d '{"status":"investigating","priority":"critical","assignee":"aml@yourbank.com"}'

Writable: status, priority, assignee, summary, addTransactionIds. Assigning an email address emails that investigator, and so does escalating a case, exactly as the console does.

Case lifecycle

A case status is a compliance record, so the API enforces the same transitions as the console. Anything else returns 409 invalid_transition and tells you which statuses are reachable from the current one.

From	Can move to
`open`	`investigating`, `escalated`, `closed`
`investigating`	`escalated`, `closed`, `sar_filed`
`escalated`	`investigating`, `closed`, `sar_filed`
`closed`	`investigating` (reopen)
`sar_filed`	nothing, a filed case is terminal

sar_filed additionally requires that a report linked to the case has actually been filed with the regulator. Without one you get 409 no_filed_report, so the ledger can never claim a filing that did not happen.

Regulatory reports

Generate a CTR, STR, SAR, NIL or PEP report from a case or a single flagged transaction. The report is built the same way the console builds it: the regulator is defaulted from your region (NG files STRs to the NFIU, elsewhere SARs to FinCEN), and the goAML tags, predicate offence, STR category and controlled indicators, are derived from the signals that actually fired on the evidence, which is what stops a filing being rejected on submission.

POST/api/v1/omniguard/reports

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/omniguard/reports \
  -H "Authorization: Bearer $DEVELOPER_KEY" -H "Content-Type: application/json" \
  -d '{"caseId":"f5db0c47-0049-464f-85ed-35966eebca78","type":"STR"}'

Response

json

{
  "report": {
    "reportId": "d39ffe12…",
    "type": "STR",
    "subject": "ACC-88213",
    "status": "draft",
    "regulator": "NFIU",
    "aiGenerated": true,
    "caseId": "f5db0c47…",
    "goaml": {
      "predicateOffence": "organized_crime",
      "strCategory": "general",
      "indicators": ["STRUCTURING"]
    }
  }
}

Pass transactionId instead of caseId to report on a single transaction, or just a subject to open a report on a party. Omit type and the right one for your region is chosen.

GET/api/v1/omniguard/reports/{id}

Returns the report, its linked case, the path to its goAML XML, and the controlled vocabularies (predicateOffences, strCategories, indicators) that the tag fields accept. GET /api/v1/omniguard/reports lists the register, filtered by status, type or caseId.

PATCH/api/v1/omniguard/reports/{id}

Request

shell

curl -X PATCH https://shield.nemesislabs.xyz/api/v1/omniguard/reports/$REPORT_ID \
  -H "Authorization: Bearer $DEVELOPER_KEY" -H "Content-Type: application/json" \
  -d '{
    "narrative": "Subject made repeated sub-threshold cash deposits across three branches.",
    "preparedBy": "Compliance Desk",
    "predicateOffence": "organized_crime",
    "indicators": ["STRUCTURING"],
    "status": "ready"
  }'

Writable: narrative, preparedBy, predicateOffence, strCategory, indicators and status. Tag values outside the goAML vocabulary are rejected, so a code the regulator would refuse never reaches a filing.

Filing stays in the console. status moves between draft and ready over the API, but not to filed. Filing is a real submission: Console → Omniguard → Reports → File to goAML validates the report, submits it to your institution's goAML web service and records the submission reference. Marking a report filed without that would put a compliance claim on record that no filing backs, so the API returns 403 filing_not_via_api.

Errors

Status	Meaning
400	Invalid body, parameters, or ids that are not yours
401	Missing, malformed or revoked developer key
403	An action that is deliberately console only, such as filing a report
404	No such function, rule, case or report on this account
409	Duplicate rule, or a case or report state change the lifecycle forbids
429	Rate limited; retry after the `Retry-After` header
502	Upstream write failure; the change was not applied

Every error carries a machine readable error slug and a detail string written for the developer reading the log.

Application & API Shield

1. Create an app and get a token

Do this once in the console, or from the management API with a dak_ developer key:

POST/api/v1/apps

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/apps \
  -H "Authorization: Bearer $DAK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"checkout-api","kind":"api"}'

Response

json

{ "appId": "3a7c...uuid", "token": "nsk_...", "kind": "api", "mode": "observe" }

2. Send traffic

The SDK does this for you (see SDKs). To integrate from any language without an SDK, POST request metadata to /observe after each response. Only the method, normalized path shape and status are sent, never bodies or secrets.

POST/api/v1/observe

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/observe \
  -H "Authorization: Bearer $NEMESIS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"events":[
    {"method":"GET","path":"/products","status":200,"authenticated":false},
    {"method":"POST","path":"/checkout","status":200,"authenticated":true}
  ]}'

Response

json

{
  "ok": true,
  "mode": "observe",
  "inLearningWindow": true,
  "policy": {
    "allowShapes": ["POST /checkout {authed}"],
    "allowPaths": ["/admin/*"],
    "updatedAt": 1699999999
  }
}

3. Enforce

Flip the app to enforce once the baseline looks right (console, or the management API below). From then on, an off-baseline request gets an HTTP 403:

POST/api/v1/apps/{id}/mode

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/apps/$APP_ID/mode \
  -H "Authorization: Bearer $DAK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"mode":"enforce"}'

Blocked-request response

json

{ "error": "blocked_by_nemesis_shield", "reason": "off-baseline request shape" }

LLM Guard

Edge network shield

Protective-DNS and egress control. It learns the domains your network normally reaches, then blocks command-and-control and data-exfiltration lookups in path. Authenticate with your Grid token (nsk_grid_…). Send each DNS query for a live verdict:

POST/api/v1/edge/decide

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/edge/decide \
  -H "Authorization: Bearer $GRID_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"queries":[
    {"domain":"app.example.com","device":"laptop-3"},
    {"domain":"beacon.c2.evil.io","device":"laptop-3","destIp":"203.0.113.66"}
  ]}'

Response

json

{
  "ok": true,
  "mode": "learn",
  "positiveSecurity": true,
  "evaluated": 2,
  "blocked": 1,
  "verdicts": [
    { "domain": "app.example.com", "decision": "allow", "reason": "on baseline", "kinds": [] },
    { "domain": "beacon.c2.evil.io", "decision": "block", "reason": "off-baseline C2", "kinds": ["c2"] }
  ]
}

decision is allow, block or monitor. If you only want telemetry rather than in-path decisions, stream logs to POST /api/v1/edge/dns instead.

Server agent

One agent per server that discovers the apps it hosts and protects them, with no DNS change. Mint an enrollment key from the management API (with a dak_ developer key), then run the one-line installer it returns on the box as root:

POST/api/v1/server-key

Request

shell

curl -X POST https://shield.nemesislabs.xyz/api/v1/server-key \
  -H "Authorization: Bearer $DAK_KEY"

Response

json

{
  "enrollKey": "ashk_...",
  "installCommand": "curl -fsSL https://shield.nemesislabs.xyz/install.sh | NEMESIS_AGENT_KEY=ashk_... sh",
  "next": "Run installCommand on the server (root). Discovered apps then appear in your console."
}

The agent self-enrolls (POST /api/agent/v1/enroll), pulls its config, heartbeats and streams events over HTTPS. Apps it discovers get their own nsk_ tokens automatically and show up under Applications, where you set each to observe or enforce.

SDKs

All integrations →

The fastest way to add Application or API Shield is the SDK: one line of middleware learns your app's normal traffic and, once you enforce in the console, blocks the rest. Every SDK is open source (MIT), sends only request shapes (never bodies or secrets), and fails open, so if the service is ever unreachable your app is unaffected. Set your nsk_ app token as NEMESIS_TOKEN and pick your stack:

Install

shell

npm install @nemesis-shield-autogon/sentinel

Protect your app

node

import express from "express";
import { sentinel } from "@nemesis-shield-autogon/sentinel/express";

const app = express();

// Learns your app's normal request shapes, then blocks the off-baseline
// ones once you switch the app to enforce in the console. No redeploy.
app.use(sentinel({ token: process.env.NEMESIS_TOKEN }));

Also ships /fastify, /koa and /llm entry points.

One contract across every language. Auth is always Authorization: Bearer nsk_…. Apps start in observe and you flip to enforce in the console (no redeploy). A blocked request returns HTTP 403 with { "error": "blocked_by_nemesis_shield" }. Every backend SDK also bundles LLM Guard (guardLLM) for AI endpoints.

Rust and a WordPress plugin are also available, and Omniguard is called directly over the REST API shown above. Need a hand wiring your stack? See how to integrate Omniguard or contact support.