Skip to main content
A push of a project with 10,000 keys in which nothing changed is one small request. This works with hashes: you compute a hash per key locally, Tolk tells you which keys are new or changed, and you send only those.

Computing hashes

A key has two hashes, both SHA-1 in lowercase hexadecimal:
string
The identity of the key: SHA-1 of namespace + "\x1F" + key + "\x1F" + (context ?? ""). The separator is the unit separator U+001F. A key without a namespace has namespace * (like lang/{locale}.json). An empty context and no context give the same hash. With the hash, a key whose name is a whole sentence never ends up in a URL.
string | null
The source text: SHA-1 of the text. For a plural key, the SHA-1 of the JSON of the forms, sorted by category, with UTF-8 unescaped (like PHP json_encode with JSON_UNESCAPED_UNICODE). null without a source text.
Check your implementation with these examples:

A push in two steps

1

Compare: POST /keys/diff

Send the hash and sourceHash of every local key (at most 10,000). Tolk responds with which hashes are new, which are changed (a different source text) and which are restored (archived in Tolk), and how many are unchanged. The diff changes nothing.
2

Send: POST /keys/sync

Send only the new, changed and restored keys, with their source text (at most 5,000 per request). A sync is safe to repeat: after a 409, that is how you finish the job.
The response counts created, updated, restored, unchanged and archived, and lists in rejected the keys that Tolk refused, with the reason (for example plural_changed: an existing key switches between singular and plural).
3

Clean up (optional)

To archive keys that have disappeared from the code, page through GET /keys, compare the hashes with the local ones and send the missing hashes in the archive field of a sync. Tolk never archives on its own.
After a sync with new or changed keys, Tolk sends the keys.synced webhook.

Key limit

The customer’s plan limits the number of active keys across all of its projects. Tolk checks a sync up front as a whole: new keys plus restored archived keys, minus the keys the same sync archives. A sync that archives as many keys as it adds therefore always fits. If it does not fit, Tolk writes nothing and responds with a 422 (the message follows Accept-Language; here en):
Do not repeat such a request: first archive keys that are no longer used, or ask Every Day for a larger plan. POST /keys/diff and reading keep working.

Reading and updating keys and translations

The fields and responses are in the API reference.