Key maps

A key map records relationships between old and new keys. A load can use it to remember the target ID created for a source record, skip already mapped inputs and later identify records eligible for rollback.

Open Key maps to inspect the maps available in your project. Keep the map name and object name with the workflow that uses them; a similarly named map from another project is not interchangeable.

Use a map in a load

Define the map name, object, source key field and, when the target returns a different identifier, target key field. Verify a small load before increasing volume:

• Each source key should resolve to the intended target key.
• Already mapped records should be skipped on a repeat load.
• Missing or failed responses must not be mistaken for successful mappings.

Deleting map entries removes evidence used for duplicate prevention and rollback. Review the affected workflow before changing them.

Query from code

The API provides GET /keymaps, POST /keymaps/lookup, GET /keymaps/{mapName}/entries and POST /keymaps/entries. Use the deployed reference for payloads and pagination. Both official SDKs expose key-map operations.

Masking tokens

A reversible masking policy uses a key-map namespace as its token vault. A vault's entries pair each token with its original, so GET /keymaps/{mapName}/entries and POST /keymaps/lookup refuse a vault with 403, and POST /keymaps/entries refuses to write into one. This applies to a map a masking policy names and to a map still holding tokens from a deleted policy. GET /keymaps still lists a vault's entry count.

The only ways to read a vault are its reversal routes. Human reversal through POST /keymaps/reverse requires keyMap:reverse and is audited. Agent reversal through POST /masking/unmask uses a one-shot approval for the specific map. keyMap:read alone never returns original/token pairs.

Rollback limits

Load rollback uses the prior run's recorded target keys. Delete mode removes target records through a configured URL. Reverse mode sends a configured POST, PUT or PATCH compensating request, for example when an accounting record must be reversed rather than deleted.

A rollback of either kind consumes its own approval, distinct from the one that authorized the load it undoes: approving a load never carries permission to reverse it, and a granted rollback covers the one run it names. Rollback is not a database transaction rollback and does not automatically restore updates, unrelated records or external side effects. Review the prior run, target, method, payload and key-map coverage before requesting it.