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

# Lemlist: Create Persona

> Create Persona. Lemlist Create Persona reference includes SDK V2 and CLI requests, input constraints, response fields, and Deepline cost.

Create Persona.

<Info>
  Tool ID: `lemlist_create_persona`
</Info>

## Run this action

Use the TypeScript SDK for a single call. Put `ctx.tools.execute(...)` inside a Play when the call should be durable, scheduled, or run across a CSV.

```ts theme={null}
import { Deepline } from 'deepline';

const deepline = await Deepline.connect();
const result = await deepline.tools.execute(
  'lemlist_create_persona',
  {
    "name": "Example",
    "filters": [
      {
        "filterId": "filter_123"
      }
    ],
    "mode": "leads"
  },
);

console.log(result.toolResponse.raw);
```

### CLI

```bash theme={null}
deepline tools execute lemlist_create_persona --input '{
  "name": "Example",
  "filters": [
    {
      "filterId": "filter_123"
    }
  ],
  "mode": "leads"
}' --json
```

## Example response

The SDK exposes this shape at `result.toolResponse.raw`. Values below are representative.

```json theme={null}
{
  "data": {
    "data": {
      "_id": "_123"
    }
  }
}
```

Use `deepline tools get lemlist_create_persona --json` for the latest machine-readable contract.

## Input reference

Creates a persona for your team from a name and a set of People Database filters. Use [Get Database Filters](/docs/api-reference/endpoints/people-database/get-database-filters) to discover the valid `filterId` values. Filters carry no `type` property: it is derived from `filterId` server-side. Filters that require a plan your team does not have are dropped silently, so the persona is stored with the subset your plan allows. Only the created id is returned. The stored `name` and `filters` are sanitized and plan-gated server-side, so echoing the request payload back would misreport what was persisted; call [List Personas](/docs/api-reference/endpoints/people-database/list-personas) to read the stored persona. This endpoint is in closed beta and answers `403` unless the beta is enabled for your team.

| Name | Type | Required | Default | Details |
| - | - | - | - | - |
| `payload.name` | `string` | Yes | — | Display name. Non-empty, and unique within your team. Minimum length: 1. |
| `payload.filters` | `array` | Yes | — | People Database filters defining the persona |
| `payload.mode` | `"leads" \| "companies"` | Yes | — | Search mode the filters target. Only `leads` is accepted today. Allowed: `leads`, `companies`. |

<details>
  <summary>Show raw input schema</summary>

  ### Input JSON Schema

  ```json theme={null}
  {
    "type": "object",
    "description": "Creates a persona for your team from a name and a set of People Database filters. Use [Get Database Filters](/api-reference/endpoints/people-database/get-database-filters) to discover the valid `filterId` values. Filters carry no `type` property: it is derived from `filterId` server-side. Filters that require a plan your team does not have are dropped silently, so the persona is stored with the subset your plan allows. Only the created id is returned. The stored `name` and `filters` are sanitized and plan-gated server-side, so echoing the request payload back would misreport what was persisted; call [List Personas](/api-reference/endpoints/people-database/list-personas) to read the stored persona. This endpoint is in closed beta and answers `403` unless the beta is enabled for your team.",
    "properties": {
      "name": {
        "type": "string",
        "description": "Display name. Non-empty, and unique within your team.",
        "minLength": 1
      },
      "filters": {
        "type": "array",
        "description": "People Database filters defining the persona",
        "items": {
          "type": "object",
          "description": "One People Database filter, as stored in a persona or a saved search. `in` includes matching values, `out` excludes them. There is no `type` property: it is derived from `filterId` server-side.",
          "properties": {
            "filterId": {
              "type": "string",
              "description": "People Database filter identifier. Use [Get Database Filters](/api-reference/endpoints/people-database/get-database-filters) to discover the valid ids."
            },
            "in": {
              "type": "array",
              "description": "Values to include",
              "items": {
                "type": "string"
              }
            },
            "out": {
              "type": "array",
              "description": "Values to exclude",
              "items": {
                "type": "string"
              }
            },
            "exactMatch": {
              "type": "boolean",
              "description": "Exact-match toggle, for the text filters that support it"
            }
          },
          "required": [
            "filterId"
          ],
          "additionalProperties": false
        }
      },
      "mode": {
        "type": "string",
        "description": "Search mode the filters target. Only `leads` is accepted today.",
        "enum": [
          "leads",
          "companies"
        ]
      }
    },
    "required": [
      "name",
      "filters",
      "mode"
    ],
    "additionalProperties": false
  }
  ```
</details>

## Output reference

Standard tool result payload.

| Name | Type | Required | Default | Details |
| - | - | - | - | - |
| `result.data` | `object` | Yes | — | Provider response payload. |
| `result.data.data` | `object` | No | — | — |
| `result.data.data._id` | `string` | No | — | Id of the created persona |
| `result.meta` | `object` | No | — | Additional response metadata (status, paging). |

<details>
  <summary>Show raw output schema</summary>

  ### Output JSON Schema

  ```json theme={null}
  {
    "type": "object",
    "description": "Standard tool result payload.",
    "properties": {
      "data": {
        "type": "object",
        "description": "Provider response payload.",
        "properties": {
          "data": {
            "type": "object",
            "properties": {
              "_id": {
                "type": "string",
                "description": "Id of the created persona"
              }
            },
            "additionalProperties": false
          }
        },
        "additionalProperties": false
      },
      "meta": {
        "type": "object",
        "description": "Additional response metadata (status, paging).",
        "additionalProperties": true
      }
    },
    "required": [
      "data"
    ],
    "additionalProperties": false
  }
  ```
</details>

## Deepline cost

* Pricing model: `fixed` (per call).
* Estimated Deepline credits: `0` per pricing unit.
* Provider-native pricing may still exist outside Deepline credit billing.

## Related documentation

* [Lemlist provider guide](/docs/providers/lemlist/guide)
* [SDK V2 quickstart](/docs/sdk-v2/quickstart)
* [SDK reference](/docs/sdk-v2/sdk-reference)
* [Run tools across a CSV](/docs/sdk-v2/batch-csv)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.