Payload Encryption
Encrypt what INFONITE sends you with AES-256-GCM, using a key only you hold
What a flow session pushes to your servers — the payload of every webhook it sends, its results included — can be delivered encrypted with a key that is yours. You mint it, you pass it once when you create the session, and from that moment those payloads exist in readable form only inside your own process. What you read with your application secret — the results endpoint, the attachments — answers over TLS and is not encrypted with it: Financial Rider and Spain Public Administration say exactly what the key covers.
Encrypted values are always self-describing: the name of the scheme, ::, and the Base64 of the encrypted bytes. Read the prefix first and handle what it says.
The scheme. Read it first — it says how to open everything after it. Here, AES-256-GCM.
The encrypted bytes. Decode it and you get the IV, the ciphertext and the authentication tag, in that order.
This page is about aes:: — AES-256-GCM, the scheme behind every encrypted webhook payload of a flow session, and the one your integration will use. The platform also accepts values encrypted towards it with RSA, for credentials travelling the other way; that is a different problem with a different answer, and it lives at the end of this page.
Encrypting with AES-256-GCM
AES-256-GCM (Galois/Counter Mode) with a 12-byte IV and a 16-byte authentication tag. GCM is authenticated encryption: decryption fails loudly if a single byte was altered in transit, so a payload that decrypts is a payload nobody touched.
The encrypted payload is delivered as a string prefixed with aes:: followed by the Base64-encoded binary data.
The raw byte layout after decoding the Base64 portion follows a strict concatenation sequence:
Encryption & Decryption Workflows
Here is the technical walkthrough for implementing the cryptography pipelines. They are the same five moves read in opposite directions — the one you implement is the top row:
Encryption Walkthrough
Decryption Walkthrough
Interactive Cryptography Sandbox
Test your GCM encryption and decryption logic directly in this sandbox tool. Toggle the switcher below to change between the Encrypt and Decrypt pipelines.
Implementation Code Examples
Select your preferred programming language tab below to copy production-ready code examples matching this AES-256-GCM specification.
Sending values in the other direction
Everything above solves one problem: we send you data, and only you can read it. There is a second, separate problem — you send us a secret, and only we can read it — and it needs a different kind of key.
It comes up when your server hands us something an engine will use on the end user’s behalf, typically a set of credentials. A shared key is the wrong tool there: whoever can encrypt could also decrypt, and both sides holding the same secret is exactly what you do not want for someone else’s password.
So each application gets an RSA key pair whose private half is generated inside the platform and never leaves it. You receive the public key — a PEM you paste into your key store, exactly as you would any other public key. Encrypt with it and nobody downstream can read the value: not an intermediary, not a log, and not your own process once the value has been sent. (An X.509 certificate carrying that same public key is available too, for stacks that expect one; it is self-signed, so it is a container with a validity window rather than a chain of trust — the key inside it is what does the work.)
Two schemes travel that way, and the choice between them is a size limit, not a preference:
The two envelopes, byte by byte
rsa:: is the simple one: the value’s UTF-8 bytes, encrypted with the public key using RSA PKCS#1 v1.5 padding, Base64-encoded, prefixed. Nothing else travels.
hybrid:: carries two things in one Base64 string: a fresh AES-256 key that only the platform can unwrap, and the value encrypted with that key — the same AES-256-GCM envelope this page describes above, laid out the same way.
Generate a new AES key and a new IV for every value. Both are cheap, and reusing either is the one way to weaken GCM. The RSA public key is the only thing you keep.
Encrypting towards us — code examples
Each example reads the public key exactly as the Console gives it — the PEM you copy or download from App Settings → Security & Keys — and produces both envelopes. All three were run against the platform’s own decryption before being published here.
The Console’s PEM is in PKCS#1 form (-----BEGIN RSA PUBLIC KEY-----). Node.js and Python read it as it is. The JDK only parses the -----BEGIN PUBLIC KEY----- form, so the Java example wraps the key into it in a dozen lines — no extra library, no certificate.