Autoscaling Report: Production databases on Neon use 2.4x less compute and 50% less cost than if they were running on a provisioned platform.
Neon
    Docs
    Log inSign up
    /API reference/Authentication/Update email provider configuration
    PATCH/projects/{project_id}/branches/{branch_id}/auth/email_provider

    Update email provider configuration

    Updates the email provider configuration for the specified branch's Neon Auth integration. The email provider handles transactional messages such as verification emails and password reset links.

    Markdown for AI context

    Quick start

    REST API - curl
    curl "https://console.neon.tech/api/v2/projects/$PROJECT_ID/branches/$BRANCH_ID/auth/email_provider" \
  -X PATCH \
  -H "Authorization: Bearer $NEON_API_KEY"
    Also available in
    neon neon-auth config email-provider update --type <type>

    Parameters

    Project ID
    project_id
    string

    The Neon project ID

    Branch ID
    branch_id
    string

    The Neon branch ID

    Request body

    6 required Required: host, port, username, password, sender_email, sender_name.

    Host
    host
    string

    Port
    port
    integer

    Username
    username
    string

    Password
    password
    string

    Sender email
    sender_email
    string

    Sender name
    sender_name
    string

    Response

    200

    The email provider configuration has been updated

    Alternative shape: set type: shared to use the shared variant (all fields optional).

    Depth
    "host": (string),req
    "port": (integer),req
    "username": (string),req
    "password": (string),req
    "sender_email": (string),req
    "sender_name": (string),req

    Errors

    default

    General error

    This endpoint can return the standard Neon API error response.

    Response fields

    • message Required. Human-readable error message.
    • code Required. Machine-readable error code.
    • request_id Optional. Request identifier for debugging. You can provide one with the X-Request-ID header.

    Retry guidance

    If no response is returned, the request may still have reached the server. This is why retry safety depends on the method and status code.

    Idempotent methods (GET, HEAD, OPTIONS) are generally safe to retry after a network error or timeout. Non-idempotent methods (POST, PATCH, DELETE, PUT) can change state, so avoid automatic retries unless your workflow can tolerate duplicate effects.

    Responses with 423 Locked or 503 Service Unavailable are safe to retry. 423 Locked means the resource is temporarily locked, usually because another operation is in progress.

    Was this page helpful?
    Previous Retrieve email provider configurationNext Retrieve localhost allow setting

    On this page

    Copy neon init command