Skip to main content
Cogentic
← All release notes

Customer records pushed over the API, and every address on a case names who holds it

Your organisation can now push its own customer records over a REST API. An alert on an address then resolves to a named customer, that customer is cited on the case and every address the case shows names its holder, compared with the KYC vendor's record. The API also gains a reference document, usage counters and a failure log, and a case opened on Redbelly now has history and balances.

2026-09-27

NewImprovementFix

This week the product learned who a wallet belongs to. Your organisation's own system pushes its customer records, an alert on an address resolves to a named person, that person is cited on the case and their name is compared with the KYC vendor's record. Alongside it, the API grew what an integrating engineer needs to trust it: a reference document, usage counters and a failure log.

  • NewCustomer push API — your organisation's own system can now push its customer records to a REST API at /api/v1/customers: name, the identifiers its KYC and monitoring vendors issued and the wallet addresses it holds. PUT, GET and DELETE a single customer by your own identifier, so nobody builds a mapping table, or send a batch of up to 500 records and receive one result per record. Requests carry an API token an organisation admin issues in settings, scoped to your organisation and hashed at rest. If-Match makes a write conditional, so a retry that lands after a newer push cannot resurrect a stale wallet list, and rate-limit headers ride every response rather than only a refusal, so a sync job can pace itself.
  • NewA push never retracts a person's work — a push replaces only the rows the same token asserted. A row a member linked by hand stays. A nightly sync that omits an identifier has not learned it is wrong, it has only not been told, so letting it retract one would make the audit trail say an officer asserted something that then vanished with nobody behind it.
  • NewAlerts and cases resolve to named customers — an alert carrying a vendor's customer reference, or whose subject or counterparty address belongs to one of your customers, now resolves to that customer and cites them on the case. An alert lists every customer it relates to with the reason for each, which covers an alert on a transfer between two of your own customers. A case opened by hand, opened from an alert, given an attached alert or given a subject now cites its customers too, where previously only alert ingest did, and a machine-made suggestion is recorded as the system, never attributed to an officer.
  • NewNames compared with the KYC record — where a case holds KYC evidence for a cited customer, the case shows the KYC vendor's name wherever that customer appears, with a line reading "your records say: {name}" when the pushed name differs. A mismatch flags, it does not block: the customer still resolves and the discrepancy sits on the case.
  • NewEvery address on a case names its holder, as evidence — every case screen that shows an on-chain address now names the customer who holds it, counterparties included: the transfers card, the explorer transfer list, the addresses card, the wallet sheet, the map node sheet, the transfer sheet and the alert sheet. Each label reads "as captured" with the time, because each investigation records the holder of every address the case holds as evidence, pinning the customer's name and revision as they were. A later rename, re-push or delete does not rewrite what the officer saw, and a closed case captures nothing, which freezes what the decision was made on. Before a case's first investigation there are no customer names on it; a customer pushed later appears on the next investigation.
  • NewA customers list — pushed customers had no screen of their own, so a member could only meet one through an alert that resolved to it. There is now a list with a total and a detail sheet, paged 20 rows at a time. It is reachable by URL only and has no navigation entry yet.
  • NewAPI reference inside the product — the customer API reference is served at /docs behind your login, with an interactive try-it panel, per-language snippets and the machine-readable specification for generating a client. It is linked from the API tokens settings screen.
  • NewA Health view for API tokens — the API tokens settings screen gains a Health section: summary tiles, a per-token row showing the last successful request and a list of recent failures, each carrying a copyable request identifier. Unlike last-used, the last successful request does not advance while every request is failing. Every JSON error body now repeats the request identifier in the body as well as the header, because sync jobs log bodies and drop headers. Failure detail records paths, codes and your own identifiers, never the values a caller sent and never the error message text, because some messages quote wallet addresses.
  • NewDelete an API token — Delete replaces Revoke as the terminal action and is offered on every row including already-revoked ones, which is the only way keys withdrawn before this leave the list. Disable is unchanged and still sits beside it as the reversible option. Customer identifiers and wallets are never deleted with the token, since the customer data outlives the key that asserted it, but those rows lose their asserter irreversibly, and the audit event records the label, scopes, status, last-used time and the counts.
  • NewRedbelly transfers and balances — a case opened on Redbelly previously had no on-chain history, no balances and no transfer lookup. It now has all three. Native RBNT and token balances are gathered; a fiat value is not available for Redbelly holdings, because the provider that serves that chain quotes a per-unit price and valuing a holding needs exact decimal arithmetic.
  • ImprovedNot supported and not configured are different answers — address attribution results now distinguish a chain no vendor serves from a vendor your organisation has not connected. Before this an organisation that had not connected a vendor was told the chain was unsupported, which was wrong and pointed at nothing you could do.
  • ImprovedThe re-screen actions and the node sheet agree — the per-vendor Re-screen action and the node sheet's list of screenable vendors now resolve through the same capability, so the sheet cannot offer a vendor the action will refuse.
  • ImprovedPerformance across chat, the case map and the long lists — chat streaming now batches its updates to the browser's animation frame rather than committing every streamed snapshot, and flushes on stream end so the last token is never lost. The case map's rendering is isolated from selection, the entity graph is capped and the React compiler is enabled across the interface.
  • FixedRotating a vendor credential asked for the wrong fields — a vendor that calls its credentials something other than an API key and secret had its own labels applied to the connect form but not the rotate form, so rotating asked for fields that vendor does not issue. Both forms now share one component.
  • FixedThe audit trail's timestamps are interactive again — audit-log rows had their timestamp popover suppressed, because the row summary sat inside a button and a timestamp popover is a button too, and nesting them is invalid. So the one place you most want the exact instant, a regulator-facing audit trail, was the one timestamp you could not hover to disambiguate. The row is rebuilt so nothing interactive is nested, and the timestamp again discloses the exact instant in your zone and in UTC, copyable. The trade-off is that the whole row is no longer a click target; only the chevron expands it.
Design partnersFounding pricing, locked. And a say in what we build next.