Bust every cached page — consumer or admin — that a write touching
customerIds could have affected.
The collection tag is always cleared alongside, because an unscoped admin page carries only that tag and no customer id can reach it.
keys deletes exact entries in addition to the tag surgery, passing the
key arguments — this cache hashes and prefixes them. It exists because
invalidateTag resolves keys through the FT index, which does not exist in
memory mode (valkeyClient: null); there the tag bust is a total no-op, and
an exact-key delete is the only thing that keeps read-after-write honest.
Services that folded get onto search pass that get's arguments.
These deletes only reach this instance's own key space, because the key space is partitioned per surface. That is sufficient, and a writer must not try to name the other surface's key:
get entry is itself tagged (by customer
id, or by the collection tag when unscoped), so the tag bust above already
evicts it from the shared L2 and publishes the peer eviction.OptionalamlVerificationStatuses?: ("REVIEW" | "PENDING" | "APPROVED" | "DECLINED")[]OptionalcountriesOfResidence?: string[]OptionalcreatedAt?: DbTimestampCriteriaOptionalcustomerIds?: string[]OptionalemailLike?: stringPartial match on email
Optionalemails?: string[]OptionalhasCustomerVerification?: booleanIdentities that have customer verification or don't.
undefined will return either.
OptionalidentityDocumentVerificationStatuses?: ("REVIEW" | "PENDING" | "APPROVED" | "DECLINED")[]Optionalids?: string[]Fetch multiple ids
OptionalincludeDeleted?: booleanOptionalnameLike?: stringPartial match on first, middle, last name or full name
OptionalorderBy?: DbOrderByCriterion<Optionalpage?: numberDefaults to 1
OptionalpageSize?: numberDefaults to 50
OptionalphoneLike?: stringPartial match on phone
Optionalphones?: string[]Optionalq?: stringUnified free-text search: matches the identity's legal name, either frozen
beneficiary alias (ach_name / wire_name), its own external id
(id_...), the owning customer's name, or the customer's external id
(cust_...). Whitespace-only values are a no-op.
OptionalreferenceIdLike?: stringPartial match on reference ID
OptionalreferenceIds?: string[]Optionalstatuses?: (OptionalupdatedAt?: DbTimestampCriteriaOptionaluuids?: string[]ProtectedsearchTags to write on a page, derived from the scope the query searched — never from the customers present in the result.
That distinction is load-bearing. An entry tagged with the customer ids in
the page carries no tags when the page is empty, so nothing can ever bust
it and a later create leaves it stale for the full L2 TTL. Tagging by
scope means an empty page still carries the tag for what it searched.
An unscoped read falls back to the collection tag, since no customer-id tag can reach a row whose owner did not exist when the entry was written.
StaticdeserializeThe inverse of serializeIdentity: rehydrates the Date fields.
OptionalamlVerification?: { id: string; status: "REVIEW" | "PENDING" | "APPROVED" | "DECLINED" }Anti-money laundering verification
Retrieve the other details directly from AiPrise
What this identity is capable of executing currently
Country of jurisdiction; alias of countryOfResidence
OptionalcustomerVerification?: { id: string }Details of customer's own verification of the identity
OptionaldateOfBirth?: stringIn ISO format: yyyy-MM-dd
OptionaldeletedAt?: DateOptionalidentityDocumentVerification?: { id: string; status: "REVIEW" | "PENDING" | "APPROVED" | "DECLINED" }Identity documents (passport, gov ID, etc.) verification
Retrieve the other details directly from AiPrise
OptionalreferenceId?: stringOptionaltaxId?: stringThe person's own tax identification number — an SSN or ITIN for a US person, the local equivalent elsewhere. Stored as entered.
Mirrors related_person.data.taxId: the two are the same fact about
the same kind of party, and both forward to AiPrise the same way
(additional_info: TAX_IDENTIFICATION_NUMBER on the identity-document
verification run — AiPrise's user profile has no field for it).
Discriminator shared with Organization for mixed entity lists
OptionalverificationProfileId?: stringAiPrise user profile ID
Only set if we verify the identity.
StaticgetThe exact cache key IdentityQueryService.get reads through.
get folds onto search, so its entry is an ordinary single-row search
page — these args must stay identical to the ones get passes
({ customerId, ids: [id], pageSize: 1 }, with search's page default of
1). Every other search filter is undefined there, and serviceCacheKey
canonicalizes with JCS, which drops undefined properties — so naming only
the four that are set produces the same digest. identityCache.test.ts
pins that equivalence.
Writers pass this to SearchCache.invalidateCache's keys so
read-after-write holds in memory mode, where tag invalidation no-ops. The
cache hashes and surface-prefixes it; this returns the arguments only.
StaticserializeIdentity → its JSON-safe form. Safe to call without a cache instance.
OptionalamlVerification?: { id: string; status: "REVIEW" | "PENDING" | "APPROVED" | "DECLINED" }Anti-money laundering verification
Retrieve the other details directly from AiPrise
What this identity is capable of executing currently
Country of jurisdiction; alias of countryOfResidence
OptionalcustomerVerification?: { id: string }Details of customer's own verification of the identity
OptionaldateOfBirth?: stringIn ISO format: yyyy-MM-dd
OptionaldeletedAt?: DateOptionalidentityDocumentVerification?: { id: string; status: "REVIEW" | "PENDING" | "APPROVED" | "DECLINED" }Identity documents (passport, gov ID, etc.) verification
Retrieve the other details directly from AiPrise
OptionalreferenceId?: stringOptionaltaxId?: stringThe person's own tax identification number — an SSN or ITIN for a US person, the local equivalent elsewhere. Stored as entered.
Mirrors related_person.data.taxId: the two are the same fact about
the same kind of party, and both forward to AiPrise the same way
(additional_info: TAX_IDENTIFICATION_NUMBER on the identity-document
verification run — AiPrise's user profile has no field for it).
Discriminator shared with Organization for mixed entity lists
OptionalverificationProfileId?: stringAiPrise user profile ID
Only set if we verify the identity.
Unless need to directly act on an identity specifically, you should be using
EntityServiceinstead.Extends IdentityCache for the bust seam its writer subclass needs, not for a read surface — this search is not cached today. Rooting it here is what lets IdentityAdminService bust the instance it reads through once it is, rather than a detached buster whose
deletecannot reach this object's L1.