Skip to main content
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: jwe header 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.
If signed MLE has not been enabled for your team, the standard path documented below applies to you.

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
This approach combines the efficiency of symmetric encryption with the security of public-key cryptography.

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
MLE requests require:
  • 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.
Host your public JWK at a well-known URL and register it with Method:
Your well-known endpoint should return:

Requirements for keys on .well-known endpoint

  1. Must have a top-level field named keys that has a list as its value.
  2. For a JWK (an item in list of keys) to be valid the following must be met:
    1. JWK must be an object
    2. JWK must have a field named kty and it must be equal to RSA
    3. JWK must have a field n and it must be a string that is valid n for a JWK in accordance with the RFC
    4. JWK must have a field e and it must be a string that is valid e for a JWK in accordance with the RFC
    5. JWK can optionally have a field named alg but if it is provided the value must match the key’s use: RSA-OAEP-256 for enc, or RS256 for sig
    6. JWK must have a field kid and it must be a string that is a valid id; on the standard MLE path this is the value you pass as cid when making requests to Method
    7. JWK can optionally have a field named use; it defaults to enc, and sig is 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
Signed MLE requests require:
  • Content-Type: application/jose
  • Request body: a compact JWE string containing a signed JWS
The 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.
Store your private signing key securely. Only register the public key with Method.

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:
You can register the key directly or include it in your well-known JWKS endpoint. See the Create MLE Public Key reference for the accepted 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 the use field:
Use an active encryption key to encrypt requests to Method. Retain every active signing key: more than one can be active during a rotation, and the response names the one that signed it.

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.
The identifiers invert between directions. On requests you send, your customer identifier is iss and Method’s identifier is aud. On responses Method returns, the two are reversed.

Step 2: Encrypt the Signed Payload

Encrypt the compact JWS using Method’s active encryption key. Set cty 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 the Method-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:
  1. Decrypt the JWE using the private encryption key identified by the JWE kid
  2. Read the inner JWS protected header and select Method’s signing key with the matching kid
  3. Verify the RS256 signature
  4. Validate the response claims
  5. Read the Method API response from the data claim
On responses, the identifiers are reversed:
  • iss is Method’s identifier
  • aud is 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-Control header)

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
Always use keys with 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:

Quick Key Deletion Example

You can delete your registered keys using the id 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
When a webhook is triggered, the event payload includes a 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:
To subscribe to these events, create a webhook using the Webhooks API with the desired event type.

Fallback Strategy

If MLE is temporarily unavailable (indicated by MLE_DECRYPTION_FAILED or MLE_ENCRYPTION_FAILED errors), you can fall back to standard non-encrypted requests by:
  1. Remove the Method-MLE: jwe header
  2. Send your payload directly (not wrapped in encrypted)
  3. Process the plain response normally
This ensures your integration remains functional even during MLE service interruptions.