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

# Update User Signature

> Updates the HTML and plain-text email signatures of a team member.

> [!NOTE]
>
> Any member of your team can be edited, including yourself: the only rule is that the user belongs to the team the API key belongs to. Send at least one of `signature` and `plainTextSignature`, and note that unknown fields are refused.

## How each signature is used

* `signature` — HTML, capped at 100,000 characters, inserted where an email carries `{{signature}}`. It is sanitized on save, so link images by URL instead of embedding them.
* `plainTextSignature` — plain text, capped at 50,000 characters, inserted by `{{plainTextSignature}}` in emails sent as plain text and in lemwarm. Line breaks are kept and HTML is converted to text.

An empty string clears a signature, and a field you omit keeps its stored value. The response returns both signatures as stored, so the HTML one may come back modified by the sanitizing. A `plainTextSignature` that passes 50,000 characters once its angle brackets are escaped is rejected as well, since the rest would be dropped on the way to plain text.


## OpenAPI

````yaml patch /users/{userId}/signature
openapi: 3.0.0
info:
  title: lemlist API
  version: 1.0.0
  description: >-
    Welcome to the lemlist Developer Documentation.


    lemlist is very customizable and open. You'll find on this page all the API
    and integration you can do with lemlist.


    # Rate Limit


    lemlist's API rate limits requests in order to prevent abuse and overload of
    our services.  

    Rate limits are applied on all routes and per API key performing the
    request.  

    The rate limits are **20** requests per **2** seconds.  

    The response provides any information you may need about it:


    | Header | Description |

    | --- | --- |

    | Retry-After | The number of seconds in which you can retry |

    | X-RateLimit-Limit | The maximum requests in that time |

    | X-RateLimit-Remaining | The number of remaining requests you can make |

    | X-RateLimit-Reset | The date when the rate limit will reset |


    _Example of values for the rate limit headers_


    ``` json

    {
        "Retry-After": 2,
        "X-RateLimit-Limit": 20,
        "X-RateLimit-Remaining": 7,
        "X-RateLimit-Reset" : "Tue Feb 16 2021 09:02:42 GMT+0100 (Central European Standard Time)"
    }

     ```

    # Definitions


    ## Team


    A team is the entity of lemlist that can handle users and billing.


    ## Credits


    Credits are the coins a team uses to enrich emails, LinkedIn URLs, etc. via
    the enrich route. Each enrichment feature needs a certain amount of credits
    to run.


    ## User


    You use a user account to connect to lemlist and send messages via the
    connected emails or LinkedIn account.


    ## Campaign


    A campaign is the entity to automate outreach. A campaign has multiple
    sequences composed of steps.


    ## Lead


    A lead is a person that you try to contact via a campaign.


    ## Activity


    An activity is the history of all the steps.


    ## Unsubscribe


    An unsubscribe occurs when a person decides they don't want to receive
    emails from you anymore.


    # Authentication


    All API routes use the dedicated subdomain `api.lemlist.com`.


    lemlist uses API keys to allow access to the API. You can get your lemlist
    API key at our [integration
    page](https://app.lemlist.com/settings/integrations).


    You need to add the `Authorization` header using the `Basic` authentication
    type. `login:password` **where the login is always empty and the password is
    the API key**.


    ⚠️ **Don't forget to add the semicolon (**`:`**) before your API key in curl
    command.**


    > To authorize, use this code: 
      

    ``` shell

    curl https://api.lemlist.com/api/team \
      --user ":YourApiKey"

     ```

    **Make sure to replace** **`YourApiKey`** **with your API key.**


    # Give feedback


    If you want to report a bug, ask for data, or share with us a use case,
    please fill this [form](https://lemlist.typeform.com/to/mfVlkyGf). It will
    help us centralize your needs!
servers:
  - url: https://api.lemlist.com/api
security:
  - basicAuth: []
tags:
  - name: Enrichment Providers
    description: >-
      The data providers lemlist can call to find an email or a phone.


      Internal providers are paid with lemlist credits and always available.
      External providers run on your own account: connect one by saving its API
      key, and it becomes available to your waterfalls. `GET
      /enrichments/providers` is the catalog of provider ids accepted by the
      waterfall endpoints.
  - name: Enrichment Waterfalls
    description: >-
      Control which data providers lemlist calls when enriching a contact, and
      in which order.


      A waterfall is an ordered list of providers for one enrichment `type`
      (`email` or `phone`). Providers are tried one after the other until one
      returns a result.


      Every team has exactly one default waterfall per type (`isDefault: true`).
      While its `editor` is `lemlist` it follows the lemlist behaviour:
      providers you connected with your own API key are tried first, then
      internal providers in a random order. Once a team member edits its
      provider list, `editor` becomes that user's id and the list is followed as
      is; resetting it hands it back to `lemlist`.


      Custom waterfalls (`isDefault: false`) carry `conditions` on the contact
      being enriched, keyed by contact property; every key present must match.
      When a contact is enriched, lemlist runs a single waterfall: the custom
      waterfall of the requested type whose conditions match the contact, or the
      default waterfall when none does. If several match, the one with the most
      condition keys wins, then the most recently updated. Only that waterfall
      runs; when it finds nothing, the enrichment ends without falling back to
      another one.
paths:
  /users/{userId}/signature:
    patch:
      tags:
        - Users
      summary: Update User Signature
      parameters:
        - name: userId
          in: path
          required: true
          description: >-
            ID of the team member whose signatures to update (usr_xxx). Any
            member of your team is allowed, including yourself
          schema:
            type: string
      requestBody:
        description: >-
          The signatures to change. Provide `signature` and/or
          `plainTextSignature`: an omitted one keeps its stored value, and at
          least one is required. Unknown fields are refused, and an invalid body
          fails the whole update, so nothing is written. The HTML signature is
          sanitized on save, so link images by URL instead of embedding them; an
          empty string clears it.
        content:
          application/json:
            schema:
              type: object
              minProperties: 1
              additionalProperties: false
              properties:
                signature:
                  type: string
                  maxLength: 100000
                  description: >-
                    HTML signature, inserted by {{signature}} in emails sent as
                    HTML. Sanitized on save; an empty string clears it
                plainTextSignature:
                  type: string
                  maxLength: 50000
                  description: >-
                    Plain-text signature, inserted by {{plainTextSignature}} in
                    emails sent as plain text and in lemwarm. Line breaks are
                    kept and HTML is converted to text; an empty string clears
                    it
            example:
              signature: <p>Best regards,<br>John Doe<br>Acme Inc</p>
              plainTextSignature: |-
                Best regards,
                John Doe
                Acme Inc
      responses:
        '200':
          description: >-
            Both signatures of the team member after the update, as stored: the
            HTML one comes back sanitized
          content:
            application/json:
              schema:
                type: object
                properties:
                  data:
                    type: object
                    properties:
                      userId:
                        type: string
                        description: ID of the team member (usr_xxx)
                      signature:
                        type: string
                        description: >-
                          HTML signature as stored after sanitizing; empty when
                          unset
                      plainTextSignature:
                        type: string
                        description: Plain-text signature as stored; empty when unset
              example:
                data:
                  userId: usr_Tq8Wm3Zk6RbP2NxYv
                  signature: <p>Best regards,<br>John Doe<br>Acme Inc</p>
                  plainTextSignature: |-
                    Best regards,
                    John Doe
                    Acme Inc
        '400':
          description: >-
            Invalid body - unknown field, wrong type, `signature` over 100,000
            characters, a `plainTextSignature` over 50,000 characters or one
            that passes 50,000 once its angle brackets are escaped
            (`SIGNATURE_INVALID_INPUT`,
            `SIGNATURE_PLAIN_TEXT_TOO_LONG_ESCAPED`), or neither field provided
            (`SIGNATURE_NOTHING_TO_UPDATE`); also a malformed userId
            (`WRONG_PARAM_USER_ID`)
          content:
            application/json:
              example:
                error: >-
                  Send only signature (HTML, at most 100,000 characters) and/or
                  plainTextSignature (at most 50,000 characters), as strings
                code: SIGNATURE_INVALID_INPUT
        '401':
          description: The API key does not resolve a user
        '404':
          description: The user is not a member of the team
          content:
            application/json:
              example:
                error: This user is not a member of your team
                code: SIGNATURE_USER_NOT_IN_TEAM
        '405':
          description: Method other than GET or PATCH
        '500':
          description: Internal server error
          content:
            application/json:
              example:
                error: Internal error
                code: INTERNAL_ERROR
components:
  securitySchemes:
    basicAuth:
      type: http
      scheme: basic

````

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