Email

This guide explains email synchronisation in both directions: LoginSign -> your platform (webhook) and your platform -> LoginSign (API).

1. LoginSign -> Your Platform (Webhook)

When a connected user's primary LoginSign email changes, LoginSign sends an email_changed event to your configured webhook URL.

{
  "type": "email_changed",
  "applicationId": "app_123",
  "connectionId": "conn_456",
  "userId": "AB1234",
  "aliasEmail": "masked@example.loginsign.com",
  "oldEmail": "old@example.com",
  "newEmail": "new@example.com",
  "changedAt": "2026-05-03T11:20:00.000Z",
  "reason": "user_email_change"
}

Recommended handling

Verify the event belongs to your application.
Update the user email in your own database by connectionId or userId.
Log old/new values for audit and incident tracing.
Process webhook delivery idempotently to avoid duplicate updates.

2. Your Platform -> LoginSign (API)

If the email changes in your own platform first, sync the new address to LoginSign with:

PATCH /api/developer/applications/:appId/users/:connectionId/email

Request body:

{
  "email": "new@example.com"
}

The endpoint requires a valid developer session and updates the user's LoginSign primary email.

Responses and conflict behavior

200 with { ok: true, changed: false } when the email is already current.
200 with { ok: true, changed: true } when the update is applied.
400 when email is missing or invalid.
404 when application or connection does not exist.
409 when the target email is already used by another user.

3. API availability test

You can verify that your app has the email sync integration endpoint configured:

POST /api/developer/applications/:appId/email-sync-api/test

4. End-to-end flow (best practice)

1) User email changes in one system (LoginSign or your platform)
2) Source system emits sync signal (webhook or API call)
3) Target system updates its record
4) Store audit log entry with old/new email and timestamp
5) Retry transient failures with exponential backoff