Shared security model
Every SDK keeps AWS credentials out of the client and depends on short-lived presigned upload URLs from your Dilnaka backend.
SDK documentation
Choose the SDK docs for your stack.
The docs section now starts with an SDK selector instead of dropping you into one language by default. Python, TypeScript, and PHP are all live today and share the same upload, auth, and completion contract.
Scoped API keys
Presigned upload flow
Shared backend contract
One upload contract
Presign, upload directly to S3, then complete the file record. The shape stays consistent so multiple SDKs can coexist without split documentation logic.
Fast route expansion
The selector now supports multiple live SDK routes without changing the top-level docs page whenever another language ships.
Per-key isolated file stores
Pro & Usage-BasedOn the Pro and Usage-Based plans, every API key you create in an app gets its own isolated file store (a storage namespace). Files uploaded with a key stay scoped to that key's store, which keeps separate integrations, environments, or clients cleanly separated. Billing, storage, and bandwidth quotas still pool at the app level, so isolation is about organization and safety, not extra cost. Free apps share a single storage area across all of their keys.
Creating a key
When you add an API key you choose Create new isolated storage to give the key a fresh, private store, or Reuse existing files to attach it to an unassigned store that already holds files.
Revoking a key never deletes files
Deleting or revoking a key detaches it from its store but keeps every file intact. The store becomes reusable and can be reassigned to a new API key, so rotating or replacing a leaked key never means re-uploading data.
Reassigning a store to a new key
- Open your app's API keys page and start creating a new key.
- Pick Reuse existing files and select the store left behind by the revoked key.
- The new key takes ownership of that store and can immediately list, serve, and manage its existing files.
A store can only belong to one active key at a time. Uploads made through a key always land in that key's store.