# 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. |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.0xpass.io/appendix/api-request-setup.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.