Encrypt a field in five minutes.

Send plaintext, get ciphertext back

Every operation is one POST to api.rypt.dev with your API token as a bearer token. Bodies are JSON, and binary fields are standard base64 with padding. This is the whole encrypt call.

$ curl -sS -X POST https://api.rypt.dev/v1/keys/0f1e2d3c-4b5a-6978-8796-a5b4c3d2e1f0/encrypt \
    -H "Authorization: Bearer ry_K3pQ7xTa_9fL..." \
    -H "content-type: application/json" \
    -d '{"plaintext":"aGVsbG8gd29ybGQ="}'

{"ciphertext":"CiQALS4vMDEyMzQ1Njc4OTo7PD0+P0BB..."}

Decrypt is the same call to /decrypt in place of /encrypt, with {"ciphertext": ...} in the body. It returns {"plaintext": ...}. The ciphertext records which key version made it, so it still decrypts after a rotation for as long as the key keeps that version, and for 7 days after the version is retired. A paid key keeps every version until you retire it. A Free key keeps only its current version, so every rotation retires the previous one: rewrap what you need onto the new version within those 7 days.

Plaintext is 1 to 65,536 bytes per call, or 8,176 bytes together with any aad on a Hardware key. The path holds the key's id. The token is redacted here; a real API token is 44 characters and starts ry_. The response shown is from a Software key. A Free or Extra wrapped key returns an envelope of rypt's own, which looks different.

From sign-in to the first ciphertext

1. Sign in at dashboard.rypt.dev. Your first sign-in creates your account and makes you its owner.
2. Create a key. Give it a name and choose its tier. A key's tier is fixed when you create it.
3. Issue an API token. It needs the encrypt and decrypt actions, which the next step runs. The quickstart on the dashboard's Overview gives it exactly those. On the API tokens page, tick them yourself. The API token is on screen once and cannot be recovered, so copy it then.
4. Make the call. The dashboard shows the encrypt and decrypt round-trip in curl, Node and Python.

Direct for small values, envelope for everything else

Direct mode is encrypt and decrypt: send the value, store what comes back. Envelope mode is for files and large objects. Ask for a data key, encrypt the data with it in your own code, keep only the wrapped key beside the data, and unwrap it when you need to read.

Every operation also takes an optional aad. A value encrypted with an aad only decrypts with the same one, which binds it to its row, file or tenant. Each operation counts once toward the key's monthly operations, rewrap included.

Every operation on a key is written down

Each create, rename, rotate, delete, restore and delete now, each retirement or restore of a key version, each change to how many versions a key keeps, and each encrypt, decrypt, wrap, unwrap and rewrap on one of your keys, writes an audit row, whether it succeeds or fails. That includes a call refused because the key is pending deletion, or because the API token may not use that key or take that action. A failed create is recorded without a key, so it appears in no key's log. Requests refused before they reach a key are not recorded, for example a bad API token, the rate limit, a firewall, malformed JSON, or a key id that is unknown, destroyed or in another container. Nor is a request that changes nothing, such as deleting a key already pending deletion.

The log is append-only. A call whose row cannot be written returns an error, never a success, though the operation may already have taken effect. After an error on a create, rename, rotate, delete, restore or delete now, check the key before you retry. A call on a key that an API token's key list or actions refuse works differently: its 403 is sent first and its row is written after, and a row that cannot be written is lost.

[{"id":48213,"ts":"2026-10-14T09:12:03.418227Z","key_id":"0f1e2d3c-4b5a-6978-8796-a5b4c3d2e1f0",
  "api_token_id":"7bd05772-cf91-4eea-86c4-e80d804610b2","user_id":null,"op":"encrypt",
  "kms_version":"1","result":"ok","error_code":null,
  "request_id":"476baa74-6abd-4d80-bc4a-f82c441e87c8","src_ip":"203.0.113.7","bytes":11,
  "kms_us":18342}]

bytes is the length of the operation's input, never its content, and kms_us is the time the operation spent in its key-management backend, in microseconds. Both are set only on encrypt, decrypt, wrap, unwrap and rewrap rows. No request or response body is ever written to rypt's logs. Read a key's log through the API or on the key's page in the dashboard.

Four tiers, priced per key

Every key has a tier and a monthly price. The calls are identical across all four. What changes is where the key material lives, how many operations and key versions the price includes, and what happens past them.

A key's tier is fixed when it is created. Hardware keys accept at most 8,176 bytes of plaintext (or data key) and aad together per call. Only the five operations above are counted, and only once the cryptography succeeds. A Free key keeps only its current version, so rotating it retires the previous version, which keeps decrypting for 7 days and is then destroyed. A paid key keeps every version it is rotated to until you retire one, by hand or by setting the key to keep at most a number of versions; a retired version keeps decrypting for 7 days and is then destroyed. Paid keys are billed by the day: a key's monthly fee is split evenly across the days of the month (UTC), and it pays for every day it exists in, even part of a day, so a key kept all month pays the price above. Deleting a key stops its billing after the day you delete it. A key's included operations are split by the day like its fee, rounded down: a Hardware key that exists for 10 days of a 30-day month is charged $11.67 and includes 83,333 operations. From December 1, 2026, each version of a paid key beyond those its price includes is billed by the day in the same way, for every day the key is billed and the version exists, a retiring version included, until the version is destroyed. No day before December 1, 2026 is billed for extra versions. The terms give the details.

{"error":"ops_cap_reached","message":"monthly operation cap reached",
 "request_id":"018f8a0e-...","cap":10000,"resets_at":"2026-10-01T00:00:00Z"}

Your keys stay with rypt

The keys themselves never reach you or your servers. You hold an API token that can use them. An API token works only with the keys in its own container, a group of keys in your account, and does only the actions it was given: encrypt, decrypt, wrap, unwrap, rewrap and rotate to use keys, create, rename, delete and restore to manage them, retire to retire their old versions, and read to list and read them, their audit logs and usage. A new API token has none unless you give it some. Giving decrypt or unwrap is in effect giving both, because each accepts the other's output. Given create, an API token can create keys in its container, paid keys included, and a paid key is billed from the day it is created. You can also hold an API token to a list of keys, which rules out create, and to the addresses a firewall allows. Give each API token only what it needs, and guard it. Access control has the details. A key rotates only when you call rotate, never on a schedule.

This is not zero-knowledge. Your plaintext reaches rypt so it can be encrypted, and rypt holds the keys that decrypt it. If that rules it out for you, use a key management service in your own cloud account instead. The security page names the one underneath and says where the keys live.

How keys are held