> ## Documentation Index
> Fetch the complete documentation index at: https://docs.methodfi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Mutual TLS (mTLS)

> Optional client-certificate authentication for teams that require it

## What is mTLS?

Mutual TLS (mTLS) adds an optional second layer of authentication to your Method integration. In addition to your API key, your application presents a client certificate on every request, and Method verifies that certificate before processing the call.

mTLS is **optional and opt-in**. It is available for teams that require it and must be provisioned per team and per environment before it takes effect. Teams that are not provisioned for mTLS continue to authenticate with their API key alone and are unaffected.

If you are interested in mTLS, contact your Method representative to have your team provisioned.

## What changes with mTLS

You continue to call the standard Method hostnames. The hostnames are the same whether or not your team uses mTLS.

```
dev.methodfi.com
sandbox.methodfi.com
production.methodfi.com
```

Once your team is provisioned for mTLS, **both** of the following are required on every request:

1. A valid client certificate
2. Your normal Method credential (an API key or OAuth access token)

After provisioning, requests without a valid client certificate are rejected, and your API key alone is no longer sufficient. Until your team is provisioned, mTLS is not enforced and your existing requests continue to work unchanged.

## Getting a client certificate

You generate a private key and a certificate signing request (CSR). You send Method the CSR, and Method returns a signed client certificate.

1. Generate your private key and CSR (see below).
2. Send Method the CSR.
3. Method returns `client.pem`, and on first issuance the CA `chain.pem` if you need it for your trust store.

<Note>
  Exchange files with Method over email or another secure channel. Your Method representative will coordinate the exchange and confirm the approved Subject DN before you generate the CSR.
</Note>

## Generate a private key and CSR

Run the following, replacing the placeholders in `-subj` with your approved values:

```bash theme={null}
openssl req -new \
  -newkey rsa:2048 \
  -nodes \
  -keyout client.key \
  -out client.csr \
  -subj "/C=US/O=<Your Organization>/OU=<Org Unit>/CN=<Approved Client Identity>"
```

This produces two files, `client.key` and `client.csr`. `client.csr` is your certificate signing request and should be sent to Method.

<Warning>
  Never send anyone your private key (`client.key`).
</Warning>

## Making authenticated requests

Present your client certificate and private key alongside your API key on every request:

<CodeGroup>
  ```bash cURL theme={null}
  curl https://production.methodfi.com/entities \
    --cert client.pem \
    --key client.key \
    -H "Authorization: Bearer sk_WyZEWVfTcH7GqmPzUPk65Vjc" \
    -H "Method-Version: 2025-12-01"
  ```
</CodeGroup>

If you received a CA chain from Method for your trust store, pass it as the trusted CA (`--cacert chain.pem` with cURL, or the equivalent in your HTTP client).

## Error handling

When mTLS is enforced for your team, requests that fail certificate validation return a `401` or `403`. See [mTLS Errors](/2024-04-04/reference/errors/mtls-errors) for the full list and response bodies.

## Certificate rotation

Renew your certificate before it expires:

1. Generate a new private key and CSR.
2. Send Method the new CSR.
3. Method registers the new certificate.
4. Deploy the new certificate. Both the old and new certificates remain valid during an agreed overlap window.
5. Method removes authorization for the old certificate once you confirm the switch.

<Note>
  If your Subject DN does not change between renewals, no configuration change is needed on Method's side.
</Note>