> For the complete documentation index, see [llms.txt](https://docs.0xpass.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.0xpass.io/appendix/api-request-setup.md).

# API Request Setup

To interact with the Passport Protocol API, there are two types of requests "Unauthenticated" which don't require an authenticated user account,  and "Authenticated" which do require an authenitcated user account. The following provides information on how the request headers for each request type works and the reasoning behind them, but you can skip to [Unauthenticated Requests](/appendix/api-request-setup/unauthenticated-requests.md) or [Authenticated Requests](/appendix/api-request-setup/authenticated-requests.md) to see how these headers are setup.

## Unauthenticated Requests

RPC request methods such as

* initiateRegistration
* completeRegistration
* initiateAuthentication
* completeAuthentication
* delegateRegistration
* executeLambda (\* depends on the lambda authorization type)

These request methods are "unauthenticated", and require you to use the 2 following request headers `x-scope-id` and `x-encrypted-key`

### Scope

| Header       | Description                                                                                                                                                                                        |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `X-Scope-Id` | Identifies the application's scope under which the user's account is being registered or authenticated. It contextualizes the request to a specific domain, enabling correct policy and procedure. |

### **End to End Encryption**

<table><thead><tr><th width="325">Header</th><th>Description</th></tr></thead><tbody><tr><td>X<code>-Encrypted-Key</code></td><td>Carries an encrypted version of AES key for the server to securely process the request, especially for operations requiring encryption or decryption of user data.<br>AES Key is random and generated locally on your device. This key is then encrypted by using Public Enclave RSA Key. You can find this key in any of the SDK examples.</td></tr></tbody></table>

### **User Identifier**

<table><thead><tr><th width="325">Header</th><th>Description</th></tr></thead><tbody><tr><td>X<code>-Encrypted-User</code></td><td><p>Carries an encrypted version of user details for the server to securely process the request. This is encrypted using the aes key which is generated above. Here is a sample user details<br></p><pre class="language-json"><code class="lang-json">{
    username: "john_doe",
    userDisplayName: "john_doe_crypto",
}

</code></pre></td></tr></tbody></table>

## Authenticated Requests

Authentication headers are essential for maintaining session integrity, authenticating user actions, and ensuring secure interactions. These apply to the following endpoints:

* eth\_signTransaction
* personal\_sign
* createLambda
* listLambda
* executeLambda (\* depends on the lambda authorization type)

### **Authentication**

Any authenticated request must containone of the following 3 headers:

<table><thead><tr><th>Header</th><th>Description</th></tr></thead><tbody><tr><td><code>X-Encrypted-Session</code></td><td>This is obtained when you authenticate with the <a data-mention href="/pages/AEfM9ykoAYQpIdz4Tt1B">/pages/AEfM9ykoAYQpIdz4Tt1B</a> endpoint. This is used by enclave to verify  your requests.</td></tr><tr><td><code>X-Encrypted-WebAuthn-Signature</code></td><td><p>This is obtained by directly singing the user object using your passkeys</p><pre><code> {
    username: "john_doe",
    userDisplayName: "john_doe_crypto",
 }
</code></pre></td></tr><tr><td><code>X-Encrypted-Key-Signature</code></td><td><p></p><p>This is obtained by directly singing the user object using your DOA key.</p><pre><code> {
    username: "john_doe",
    userDisplayName: "john_doe_crypto",
 }
</code></pre></td></tr></tbody></table>

### **End to End Encryption**

<table><thead><tr><th width="321">Header</th><th>Description</th></tr></thead><tbody><tr><td><code>X-Encrypted-Key</code></td><td>Carries an encrypted version of AES key for the server to securely process the request, especially for operations requiring encryption or decryption of user data.<br>AES Key is random and generated locally on your device. This key is then encrypted by using Public Enclave RSA Key. You can find this key in any of the SDK examples.</td></tr></tbody></table>

### **User Identifier**

<table><thead><tr><th width="325">Header</th><th>Description</th></tr></thead><tbody><tr><td>X<code>-Encrypted-User</code></td><td><p>Carries an encrypted version of user details for the server to securely process the request. This is encrypted using the aes key which is generated above. Here is a sample user details<br></p><pre class="language-json"><code class="lang-json">{
    username: "john_doe",
    userDisplayName: "john_doe_crypto",
}

</code></pre></td></tr></tbody></table>

### Scope

| Header       | Description                                                                                                                                                                                        |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `X-Scope-Id` | Identifies the application's scope under which the user's account is being registered or authenticated. It contextualizes the request to a specific domain, enabling correct policy and procedure. |