API Reference
API Reference

Account Modification

post
https://api.signifyd.com/v3/accounts/events/modifications

The Account Modification API is designed to detect risky changes made to user accounts after login - especially in sessions that may have been compromised. It analyzes behavioral, device, and contextual signals in real time to assess the legitimacy of sensitive updates such as email, password, or payment method changes. The API returns a recommended action, enabling proactive intervention before downstream fraud occurs.

Use this endpoint when a user attempts to update sensitive account information, such as changing their email, password, address, or stored payment method. By incorporating this check into your modification flow, you can identify mid session ATO behavior and prevent attacks like card testing.

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
Body Params
string
required

A unique identifier for the modification event.

modificationTypes
array of strings
required

The types of modification to the account.

  • EMAIL_UPDATE - The user has requested to update their email address.
  • PASSWORD_CHANGE - The user has requested to change their password.
  • PAYMENT_METHOD_ADD - The user has requested to add a payment method.
  • ADDRESS_UPDATE - The user has requested to updated their address.
  • PHONE_UPDATE - The user has requested to update their phone number.
  • NAME_UPDATE - The user has requested to update their full name.
  • OTHER_UPDATE - The user has requested to update something different from the above.
modificationTypes*
Allowed:
date-time
required

The date and time of when the user requested the account modification.

Formatted as yyyy-MM-dd'T'HH:mm:ssZ per ISO-8601.

string

New email address, required when EMAIL_UPDATE is present in modificationTypes.

string

New phone number, required when PHONE_UPDATE is present in modificationTypes.

string

New full name, required when NAME_UPDATE is present in modificationTypes.

newPayment
object

New payment details, required when PAYMENT_METHOD_ADD is present in modificationTypes.

newAddress
object

New address object, required when ADDRESS_UPDATE is present in modificationTypes.

string
enum

needed Method used for authentication.

  • PASSWORD - User provided a password for this login attempt.
  • PASSKEY - User provided a passkey for this login attempt.
  • GOOGLE - User logged in with a Google account.
  • FACEBOOK - User logged in with a Facebook account.
  • APPLE - User logged in with an Apple account.
  • LINKEDIN - User logged in with a LinkedIn account.
  • X - User logged in with an X account.
  • EMAIL_OTP - User logged in with an email one time password.
  • PHONE_OTP - User logged in with a phone one time password.
  • OTHER - User logged in with a different method from the ones listed above.
date-time

needed The date and time of the previous successful login.

Formatted as yyyy-MM-dd'T'HH:mm:ssZ per ISO 8601. See the dates section of the Introduction for more information about date formats.

userAccount
object
required

Current context on the account being modified.

device
object

needed Device & fingerprint context.

sessionMetadata
object

Optional authentication session context details.

string
enum

needed The channel through which the account integrity event was initiated.

  • WEB - Event originated from a web browser.
  • MOBILE_APP - Event originated from a native mobile application.
Allowed:
tags
array of strings

A list of attributes or short descriptors associated with the account modification.

tags
Headers
int64

The team id requested for authentication. This should normally be omitted, as it's only relevant when auth credentials allow requests for multiple teams.

string
enum

Override the decision response for testing Account Integrity API integrations.
This header allows you to specify the exact decision you want returned, bypassing normal
decision processing. Only valid for test teams.

Available actions:

  • ALLOW - Let the event proceed normally. No additional checks are needed.
  • DENY - Reject the event outright and do not persist or apply the change.
  • STEP_UP - Pause the flow and require extra verification (for example, MFA or a challenge).
  • FLAG - Allow the event. Signifyd will use this flag in downstream flows like checkout to apply added scrutiny where needed.
  • ALERT - Allow the event but immediately notify the user of unusual activity (for example, via email or SMS).
Allowed:
Responses

Updated 7 days ago

Did this page help you?
Language
Credentials
Basic
base64
:
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json

Updated 7 days ago

Did this page help you?

Terms

Acceptable Use

Privacy

Your privacy choices