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. The entries API returns old and new values to callers with keyMap:read. For a token vault this can expose original/token pairs even without keyMap:reverse. Restrict read access as well as reversal; absence of the reverse permission is not a confidentiality boundary.

Human reversal through POST /keymaps/reverse requires keyMap:reverse. Agent reversal through POST /masking/unmask uses a one-shot approval for the specific map. Those dedicated reversal gates do not prevent an allowed entries read from exposing the stored 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.