All integrations

Enigma

DATA · DATA & ANALYTICS

Sanctions and watchlist screening, plus KYB business verification, on their own key.

Connecting Enigma in practice

Enigma is a single GraphQL endpoint whose limits are described but never quantified: the docs say a plan has an RPS limit, a burst limit and a daily limit, publish no figure for any of them, and tell you to read Retry-After on every 429 "Slow Down". Nested connections also default to different page sizes — commonly first: 100 in one place and first: 3 in another — so an unparameterised query silently truncates.

Scopes that draw scrutiny

  • x-api-key The only credential the GraphQL API accepts. There is no scope mechanism, so the same key reaches business identity and activity data and the KYB identity-verification calls alike.

Rate limits

  • Three separate per-plan ceilings are enforced: requests per second, a burst limit, and a daily limit. The documentation publishes no number for any of them.
  • Exceeding a limit returns 429 "Slow Down" with a Retry-After header in seconds, and the docs ask that you wait at least that long before retrying.

Worth knowing

  • Relay-style cursor pagination with `first`/`last` and `after`/`before`, and the default page size varies by field — commonly first: 100, but as low as first: 3 on some connections — so one query can quietly return three rows.
  • Because no rate figure is published, the only way to learn your ceiling is to trip it, which makes capacity planning an operational exercise rather than a design one.
  • The KYB and business-verification calls live under the same key as the bulk data reads, so an agent that only needs a lookup is holding the identity-verification surface too.

Checked against Enigma GraphQL API reference (2026-09-29), Enigma documentation (2026-09-29)

Acts as the person, not as itself

Each user connects their own account. Every call carries both identities — the agent and the person it is acting for — so the agent can never reach past what that individual can already do.

Credentials never touch the agent

Tokens live in the vault and attach server-side at call time. The agent holds a session, not a secret, and revoking access does not mean rotating a key.

Every call on the record

Who asked, which agent acted, which action ran, and the verdict that let it through — one audit trail across every integration, not one per vendor.

What an agent can do

Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.

enigma_get_kyb_by_task_idREAD

Read a KYB verification task and its result via GET /v2/kyb/{task_id}, using the task id `enigma_post_kyb` returned. A task id that does not exist answers 404 {"error":true,"message":"task not found"}.

api
enigma_post_decisions_get_manyREAD

List archived screening decisions via POST /evaluation/sanctions/decisions/get_many, filtered and paginated by query parameters. Decisions exist only where case management is enabled (`configuration_overrides.general.use_case_manager` on the screening request, or `general.use_case_manager` in the account's stored configuration), so an empty list can mean 'case management is off' rather than 'nothing was screened'.

api
enigma_post_decisions_get_one_by_decision_idREAD

Read one archived screening decision via POST /evaluation/sanctions/decisions/get_one/{decision_id}. Decisions exist only when case management is enabled for the account or for the screening request (`configuration_overrides.general.use_case_manager`); an account that has never enabled it has nothing to read. The decision id is the `request_id` the screening response returned.

api
enigma_post_decisions_update_oneWRITE

Update one archived screening decision via POST /evaluation/sanctions/decisions/update_one -- set its status, assign it to a reviewer, or attach notes. The decision is named in the BODY as `request_id`, not in the path. This writes to the account's compliance case record: a status change here is the auditable disposition of a sanctions alert, so it is a write on a shared record rather than on anything this connection owns.

api
enigma_post_entity_by_provider_by_collection_by_record_id_by_formatREAD

Read the full profile of one watchlist entity via POST /evaluation/sanctions/entity/{provider}/{collection}/{record_id}/{format}. The four segments come from the `entity` object on a screening hit, which carries the entity id and its lookup URL, so this is the follow-up to a `enigma_post_screen` alert rather than a call made from nothing. The response carries names, aliases, date of birth, nationality, addresses, identification documents, programme designations and source-list information; `format` chooses the representation.

api
enigma_post_kybWRITE

Start a KYB verification task for one business via POST /v2/kyb. Queries Enigma's business data -- Secretary of State records and related authoritative sets -- and optionally runs TIN/SSN checks and watchlist screening against sanctions, debarment and PEP lists. TWO MUTUALLY EXCLUSIVE REQUEST FORMS: the SINGLE form carries `name` (required) plus optional `website`, `tin`, `address` and `person`; the MULTIPLE form carries everything nested inside `data` (up to 2 names, 2 addresses, 1 website, 1 person, 1 TIN). Mixing them is refused -- by this connector by name, and by Enigma with a 400. If an `address` is given it must carry at least one of city, state or postal_code. This is a metered write: it creates a task and consumes the account's KYB quota, and the response's task id is read back with `enigma_get_kyb_by_task_id`.

api
enigma_post_screenWRITE

Screen customers, entities and free text against sanctions and other watchlists via POST /evaluation/sanctions/screen. `searches` is an array of search objects, each `type` one of ENTITY, TEXT, LLM_ENTITY, LLM_TEXT: an ENTITY search carries an `entity_description` (person_name, org_name, address, dob as yyyymmdd, country_of_affiliation -- each an array of strings) and a TEXT search carries a `text` string. The response carries `request_id`, an `alert` boolean, `configuration_used`, and one `search_results` entry per search with its scored `hits`. `configuration_overrides` overrides the account's stored thresholds, weights, `max_results` and `list_groups` for this one request. This is a WRITE: with case management enabled (`configuration_overrides.general.use_case_manager`) each request is archived as a decision that `enigma_post_decisions_get_many` then lists.

api
enigma_post_viewsREAD

List every watchlist view this account can screen against, via POST /evaluation/sanctions/views. Takes no parameters and no body. The names it returns are what go in `configuration_overrides.list_groups` on a screening request, so this is the discovery call for the whole screening surface, and the views an account sees depend on its Enigma entitlements. NOTE THE VERB: Enigma's documentation calls this a GET, but api.enigma.com serves POST and OPTIONS on this resource and nothing else -- measured 2026-09-23, see _measurements.views_is_a_post.

api

Put Enigma behind one governed endpoint.

Same permissions, same audit trail, whatever else you connect next.