This page documents two message level encryption modes.
- Standard MLE is available to every team. It encrypts the request and response bodies with a
Method-MLE: jweheader and an{"encrypted": "..."}envelope. - Signed MLE is optional and opt-in on top of standard MLE. It signs the payload before encrypting it, which authenticates the sender in both directions. To enable it, contact your Method representative.
What is Message Level Encryption?
Message Level Encryption (MLE) provides end-to-end encryption for sensitive data transmitted between your application and Method’s API. Using a hybrid encryption approach, MLE ensures your data remains protected even if network traffic is intercepted. MLE uses two layers of encryption:- Symmetric encryption (AES-GCM) encrypts your actual data payload using a Content Encryption Key (CEK)
- Asymmetric encryption (RSA-OAEP-256) encrypts the CEK using Method’s public key
Prerequisites
To use MLE with Method’s API, you’ll need:- An RSA key pair for RSA-OAEP-256
- Ability to create and parse JWE (JSON Web Encryption) in compact serialization format
- Header:
Method-MLE: jwe - Content-Type:
application/json - Request body:
{"encrypted": "<compact dot separated JWE string>"}
Setup Guide
Step 1: Generate Your RSA Key Pair
Generate an RSA key pair that will be used to receive encrypted responses from Method.Step 2: Register Your Public Key with Method
You can register your public key using either a well-known endpoint (recommended) or direct registration.Important: Each key ID (
kid) can only be registered once using either method. If you have a public key available through your well-known endpoint, you should not register the same public key through direct registration, even if you change the kid.Option A: Well-Known Endpoint (Recommended)
Host your public JWK at a well-known URL and register it with Method:Requirements for keys on .well-known endpoint
- Must have a top-level field named
keysthat has a list as its value. - For a JWK (an item in list of
keys) to be valid the following must be met:- JWK must be an object
- JWK must have a field named
ktyand it must be equal toRSA - JWK must have a field
nand it must be a string that is validnfor a JWK in accordance with the RFC - JWK must have a field
eand it must be a string that is validefor a JWK in accordance with the RFC - JWK can optionally have a field named
algbut if it is provided the value must match the key’suse:RSA-OAEP-256forenc, orRS256forsig - JWK must have a field
kidand it must be a string that is a validid; on the standard MLE path this is the value you pass ascidwhen making requests to Method - JWK can optionally have a field named
use; it defaults toenc, andsigis accepted for signing keys on the signed MLE path
Option B: Direct Registration
Alternatively, register your public key directly:Step 3: Retrieve Method’s Public Key
Fetch Method’s public key for encrypting your requests:Method’s JWKS also publishes signing keys, which carry
use: "sig" and alg: "RS256" and are used only on the signed MLE path. Filter on use as well as status when selecting a key for encryption.Method’s public keys are environment-specific:
- Production:
https://production.methodfi.com/.well-known/jwks.json - Sandbox:
https://sandbox.methodfi.com/.well-known/jwks.json - Development:
https://dev.methodfi.com/.well-known/jwks.json
Making Encrypted Requests
Step 1: Encrypt Your Request Payload
Step 2: Send the Encrypted Request
Step 3: Decrypt the Response
Complete Example
Here’s a complete example showing the full MLE flow:Signed Message Level Encryption
Signed Message Level Encryption (signed MLE) adds sender authentication to standard MLE. Requests are signed with your private signing key before they are encrypted, and responses are signed by Method before they are encrypted to your public encryption key. Signed MLE uses nested JOSE tokens:- The request or response payload is signed as a JWS using RS256
- The signed JWS is encrypted as a JWE using RSA-OAEP-256 and AES-GCM
Signed MLE is optional and is not enabled by default. To enable it, contact your Method representative.
Prerequisites
To use signed MLE, you’ll need:- An RSA encryption key pair for RSA-OAEP-256
- An RSA signing key pair for RS256
- Ability to create and parse compact JWS and JWE tokens
- The customer and Method identifiers provided during setup
- Content-Type:
application/jose - Request body: a compact JWE string containing a signed JWS
Method-MLE: jwe header and {"encrypted": "..."} wrapper used by standard MLE are not used for signed MLE.
Setup Guide
Step 1: Generate Your Signing Key Pair
Generate a separate RSA key pair for signing requests.Step 2: Register Your Signing Public Key with Method
Register your signing public key through the same MLE public keys endpoint used for encryption keys. The signing JWK must include:use and alg values and for the well-known requirements that apply to signing keys.
Signed MLE requests carry no
cid, so Method selects the response encryption key itself: among your active use: "enc" registrations that are within their nbf and exp window, the one with the highest iat wins. Register an iat on every encryption key if more than one will ever be active at a time. Without it the choice is ambiguous and the request fails with MLE_ENCRYPTION_KEY_UNAVAILABLE.Step 3: Retrieve Method’s Public Keys
Method publishes both encryption and signing keys from the same JWKS endpoint. Select keys using theuse field:
Making Signed Encrypted Requests
Step 1: Sign Your Request Payload
Create a JWT claims object containing your request data, then sign it as a compact JWS using your private RS256 signing key. The signed payload includes:
You can also include standard JWT claims such as
iat and jti.
Step 2: Encrypt the Signed Payload
Encrypt the compact JWS using Method’s active encryption key. Setcty to JWT to indicate that the encrypted content is a signed JWT.
Step 3: Send the Signed Encrypted Request
Send the compact JWE directly as the request body. Set theMethod-Version header as described in Versioning; without it, the request uses your team’s default API version.
Processing Signed Encrypted Responses
Signed MLE responses use the same nested format: a signed JWS encrypted inside a JWE. To process a response:- Decrypt the JWE using the private encryption key identified by the JWE
kid - Read the inner JWS protected header and select Method’s signing key with the matching
kid - Verify the RS256 signature
- Validate the response claims
- Read the Method API response from the
dataclaim
issis Method’s identifieraudis your customer identifier
Signed MLE responses use
Content-Type: application/jose, including errors raised after your request has been decrypted and verified. Decrypt and verify those the same way; the HTTP status is preserved. Errors raised before that point, such as a malformed JWE or a rejected signature, are returned as a standard JSON error. Branch on the response Content-Type.Error Handling
When using MLE, you may encounter these specific error codes:Performance Considerations
- MLE requests have increased latency due to encryption/decryption operations
- Consider implementing request timeouts appropriately
- Cache Method’s public keys (respect the
Cache-Controlheader)
Key Lifecycle and Management
Method’s Key Status
Method’s public keys have two possible statuses:- Active: Current keys, each usable for its declared
use— encryption keys for encrypting your requests, signing keys for verifying Method’s responses - Deprecated: Keys that are being phased out and will be disabled in 90 days
status: "active" when fetching Method’s public keys. Deprecated keys remain functional for 90 days before being completely disabled.
Method’s JWKS contains both encryption keys (use: "enc", alg: "RSA-OAEP-256") and signing keys (use: "sig", alg: "RS256"). Filter on use as well as status: select an encryption key to encrypt your requests, and, on the signed path, a signing key to verify Method’s response signatures. Every published key also carries numeric iat, nbf, and exp claims.
Your Key Management
When you successfully register a key with Method, you’ll receive a response like this:MLE Public Keys API
For complete CRUD operations on your MLE public keys, see the dedicated API documentation:- Create MLE Public Key - Register a new public key
- List MLE Public Keys - Get your active registered keys
- Retrieve MLE Public Key - Get a specific key by ID
- Delete MLE Public Key - Delete (disable) a specific key
Quick Key Deletion Example
You can delete your registered keys using theid returned when you created the key:
Key Rotation Best Practices
- Method recommends rotating your keys every 90 days
- Always check for keys with
status: "active"when fetching Method’s keys - Plan your key rotation to avoid service interruptions
Webhook Notifications
You can subscribe to webhook events to be notified when Method’s public keys change:
These webhooks fire for Method’s signing keys as well as its encryption keys. They help you stay informed about Method’s key lifecycle changes, allowing you to:
- Automatically fetch new active keys when they’re created
- Update your cached keys when Method rotates or deprecates keys
- Implement proactive key management in your application
path field pointing to the specific key that changed. You can use this path to retrieve the updated key information via the Retrieve Method Public Key endpoint.
Example webhook event:
Fallback Strategy
If MLE is temporarily unavailable (indicated byMLE_DECRYPTION_FAILED or MLE_ENCRYPTION_FAILED errors), you can fall back to standard non-encrypted requests by:
- Remove the
Method-MLE: jweheader - Send your payload directly (not wrapped in
encrypted) - Process the plain response normally