Encrypted request payloads
Turn on acceptOnlyEncryptedData for a database, a table, an API, a custom or system API, and plain bodies and query strings are refused.
API Maker
The backend engine for the AI era
Security
Encrypted payloads, allowed origins, two-factor sign-in and package audits, on top of tokens and groups.
Beyond who may call what, API Maker can require encrypted request bodies and return encrypted responses, refuse browsers from other origins, ask a second factor when people sign in to the admin panel, and check the packages of your sandboxes, in every language, for known vulnerabilities.
Step through it, slow it down, or open the full canvas.
Only the browsers of your apps. List the origins of your web apps. A browser request from any other origin gets 403 before anything runs. Calls without an Origin header, like servers, are not affected.
List the origins of your web apps. A browser request from any other origin gets 403 before anything runs. Calls without an Origin header, like servers, are not affected.
The app encrypts { data, createdAt } with the transfer key of your secret and sends dataEncFE. Turn on acceptOnlyEncryptedData and plain bodies are refused.
The payload carries its creation time. Sent again after feTransferDataValidityInSeconds, 300 seconds here, it is refused: Payload expired.
x-am-get-encrypted-data asks for the answer in encryptedData, alone or next to data.
The root user can require a code from an authenticator app, a code sent by email, or both. Recovery codes are shown once and stored hashed.
The vulnerabilities page audits the packages you add to your sandboxes, in every language, and the Rust crates API Maker is built from.
Turn on acceptOnlyEncryptedData for a database, a table, an API, a custom or system API, and plain bodies and query strings are refused.
Schema conversions store sensitive fields encrypted or as HMAC SHA-256 hashes, with the keys of your secret.
The root user can require a code from an authenticator app, a code sent by email, or both, when people sign in to the admin panel. Recovery codes are shown once and stored hashed.
A partner network ends TLS at its own proxy before the traffic reaches your server. The app encrypts each body with the transfer key, so the proxy only sees ciphertext, and a captured request can not be replayed after a few minutes. Admin users sign in with their authenticator app.
POST /api/schema/admin/shop/main/orders/save-single-or-multiplex-am-authorization: <API user token>x-am-encrypted-payload: truex-am-get-encrypted-data: get_only_encryption{ "dataEncFE": "U2FsdGVkX1+q3n…" }dataEncFE is { data, createdAt } encrypted with encryptionAlgorithmFETransfer and secretFETransfer of the secret, the key you share with your frontend or mobile app.
common: <T.ISecretTypeCommon>{ encryptionAlgorithmFETransfer: 'AES', secretFETransfer: '…', feTransferDataValidityInSeconds: 300, // older payloads are refused},On the real admin panel, with real data.
No. They add a second layer on top of HTTPS, useful when TLS ends before API Maker or when the body must stay opaque to intermediaries.
The root user: email codes, authenticator codes, recovery codes, code length and expiry, attempts and resend delay.
Write to [email protected] with the steps to reproduce it. Please give us time to fix it before you publish.