The login (email address) of the user

The user's password

Identifier of user's current device

Multi-factor verification code

Profile (formerly "Client") API key

The identity provider.

Third-party authentication token used to authenticate with the Identity Provider. Required if identityProvider is different than SYNERISE.

Profile email. Required if identityProvider is SYNERISE and email is the unique identifier (default setting).

Profile customId. Required if identityProvider is SYNERISE and customId is the unique identifier (see https://hub.synerise.com/docs/settings/configuration/non-unique-emails/).

Profile password. Required if identityProvider is SYNERISE.

Profile UUID. Required if identityProvider is SYNERISE.

Unique Android or iOS device ID

This object contains the marketing agreements of the Profile.

You can also pass the values as strings ("true";"True"/"false";"False") or integers (1 for true and 0 for false).

This object contains custom attributes that can have any name (except for reserved attributes, see warning below) and data type, as required by your integration.

The attribute names can't include any characters that match the pattern (ECMA flavor): /[\r\n\u2028\u2029\u00AD\u0000\uFE00-\uFE0F]/

String values:

• can't include variation selectors ([\uFE00-\uFE0F]), unless there are other characters in the string.
• can't include the "null" control character (\u0000)

If you want to send a date/time attribute for use in analytics, take the following into account:

• The date/time should be formatted according to ISO 8601.
• The time zone of the workspace affects dates/times in the attributes that DON'T have a defined timezone. Example:
  • 2023-10-09T12:00:00 doesn't have a timezone indicator and will be considered as a time in the workspace's time zone.
  • 2023-10-09T12:00:00+02:00 has a timezone indicator (+02:00), so the timezone of the workspace doesn't affect it.
  • 2023-10-09T12:00:00Z is a time in the UTC time zone (denoted by the Z at the end), so the timezone of the workspace doesn't affect it.

WARNING: Some attributes are reserved and cannot be sent. If you send them, they are ignored.

The IP address of the client device that is logging in.

Profile (formerly "Client") API key

The identity provider.

Third-party authentication token used to authenticate with the Identity Provider. Required if identityProvider is different than SYNERISE.

Profile email. Required if identityProvider is SYNERISE and email is the unique identifier (default setting).

Profile customId. Required if identityProvider is SYNERISE and customId is the unique identifier (see https://hub.synerise.com/docs/settings/configuration/non-unique-emails/).

Profile password. Required if identityProvider is SYNERISE.

Profile UUID. Required if identityProvider is SYNERISE.

Unique Android or iOS device ID

This object contains the marketing agreements of the Profile.

You can also pass the values as strings ("true";"True"/"false";"False") or integers (1 for true and 0 for false).

This object contains custom attributes that can have any name (except for reserved attributes, see warning below) and data type, as required by your integration.

The attribute names can't include any characters that match the pattern (ECMA flavor): /[\r\n\u2028\u2029\u00AD\u0000\uFE00-\uFE0F]/

String values:

• can't include variation selectors ([\uFE00-\uFE0F]), unless there are other characters in the string.
• can't include the "null" control character (\u0000)

If you want to send a date/time attribute for use in analytics, take the following into account:

• The date/time should be formatted according to ISO 8601.
• The time zone of the workspace affects dates/times in the attributes that DON'T have a defined timezone. Example:
  • 2023-10-09T12:00:00 doesn't have a timezone indicator and will be considered as a time in the workspace's time zone.
  • 2023-10-09T12:00:00+02:00 has a timezone indicator (+02:00), so the timezone of the workspace doesn't affect it.
  • 2023-10-09T12:00:00Z is a time in the UTC time zone (denoted by the Z at the end), so the timezone of the workspace doesn't affect it.

WARNING: Some attributes are reserved and cannot be sent. If you send them, they are ignored.

Profile (formerly "Client") API key

The identity provider.

Third-party authentication token used to authenticate with the Identity Provider. Required if identityProvider is different than SYNERISE.

Profile email. Required if identityProvider is SYNERISE and email is the unique identifier (default setting).

Profile customId. Required if identityProvider is SYNERISE and customId is the unique identifier (see https://hub.synerise.com/docs/settings/configuration/non-unique-emails/).

Profile password. Required if identityProvider is SYNERISE.

Profile UUID. Required if identityProvider is SYNERISE.

Unique Android or iOS device ID

This object contains the marketing agreements of the Profile.

You can also pass the values as strings ("true";"True"/"false";"False") or integers (1 for true and 0 for false).

This object contains custom attributes that can have any name (except for reserved attributes, see warning below) and data type, as required by your integration.

The attribute names can't include any characters that match the pattern (ECMA flavor): /[\r\n\u2028\u2029\u00AD\u0000\uFE00-\uFE0F]/

String values:

• can't include variation selectors ([\uFE00-\uFE0F]), unless there are other characters in the string.
• can't include the "null" control character (\u0000)

If you want to send a date/time attribute for use in analytics, take the following into account:

• The date/time should be formatted according to ISO 8601.
• The time zone of the workspace affects dates/times in the attributes that DON'T have a defined timezone. Example:
  • 2023-10-09T12:00:00 doesn't have a timezone indicator and will be considered as a time in the workspace's time zone.
  • 2023-10-09T12:00:00+02:00 has a timezone indicator (+02:00), so the timezone of the workspace doesn't affect it.
  • 2023-10-09T12:00:00Z is a time in the UTC time zone (denoted by the Z at the end), so the timezone of the workspace doesn't affect it.

WARNING: Some attributes are reserved and cannot be sent. If you send them, they are ignored.

Profile (formerly "Client") API key

UUID of the Profile. It is a unique identifier.

The value can't include any characters that match the pattern (ECMA flavor): /([\uD800-\uDBFF][\uDC00-\uDFFF])|([\r\n\u2028\u2029\u00AD]|[\uFE00-\uFE0F]|[\u0000])/

You must provide at least one of those profile identifiers.

How much the total cost decreased

Any custom parameters

ID of the transaction. If you want to be able to overwrite this transaction in the future, you use eventSalt. If you send a transaction with the same orderId multiple times, the system generates multiple transaction events.

Payment details

A list of items in the transaction.

Each item creates a product.buy event. The UUID of that event is generated from a combination of:

• the UUID of the transaction.charge event created by the transaction
• the position of the item in this array. This has an effect on updating transaction events.

This means that when you update a transaction (a transaction can only be updated if it has an eventSalt and the same timestamp as the original), you must keep the original order of items in the array. Otherwise, you may accidentally overwrite a product.buy event with another item's event. The system does NOT recognize the item by SKU in this case.

Example:

1. You create a transaction with items A, B, and C (in that order).
2. You update the transaction and the items are now A, B, D, and C (in that order).
3. Because item D took the position of C in the event, it has the same UUID as C had earlier. The event of D overwrites the event of C, and C is generated as a new event.

Additionally, because events can't be deleted from the database, cancelled items remain as events in a Profile's history. You can use a custom free-form property to tag items as cancelled. This way, you can keep cancelled items in products when updating a transaction without breaking the order of items. You can also use the property to filter cancelled items out in Analytics.

Time when the event occurred, in ISO 8601.

This time isn't affected and doesn't affect the timezone of your workspace - you can send events with a timezone different than that of the workspace. Synerise calculates the times into UTC standard when saving events in the database.

If not defined, the backend inserts the time of receiving the event.

A time with a "Z" at the end (for example, 2022-10-14T12:02:06Z) denotes a time in the UTC standard.

If you want to send time in a different timezone, you can do this by appending {+|-}hh:mm at the end of the string.

Note that if the timezone is ahead (+) of UTC, the UTC time is calculated by subtraction. When the timezone is behind (-) UTC, the UTC time is calculated by addition.
For example:

• if your timezone is UTC+1, append +01:00. When you send 2022-10-14T15:00:000+01:00, it is saved in the database as 2022-10-14T14:00:000Z
• if your timezone is UTC-8, append -08:00. When you send 2022-10-14T22:00:000-08:00, it is saved in the database as 2022-10-15T06:00:000Z (note that the date also changes between timezones in this example)

IMPORTANT: If you send an event with a future time, the parameter is rejected and the time of receiving the event is saved as the occurrence time. For example, if your timezone is UTC+1 and you send the event at 15:00 local time, future times are:

• later than 15:00 local time
• later than 14:00 UTC

When you retrieve an event, its time is always shown as UTC. The original time string that you sent (even if it was a future time and was rejected) can be retrieved with the activities endpoints, as snr-original-time.

Transaction revenue (amount after taxation). This field is not calculated automatically by the backend, you must provide the value by summing up the results of finalUnitPrice * quantity from all items in the products array.

If you want to display the price before taxation, use this object. If you only want to display the price after taxation, set the values to the same as in revenue.

Source of the event.

This parameter is required, but not saved in the database. It can't be used in Analytics, Automations, and so on.

You must provide at least one of those profile identifiers.

Time when the event occurred, in ISO 8601.

This time isn't affected and doesn't affect the timezone of your workspace - you can send events with a timezone different than that of the workspace. Synerise calculates the times into UTC standard when saving events in the database.

If not defined, the backend inserts the time of receiving the event.

A time with a "Z" at the end (for example, 2022-10-14T12:02:06Z) denotes a time in the UTC standard.

If you want to send time in a different timezone, you can do this by appending {+|-}hh:mm at the end of the string.

Note that if the timezone is ahead (+) of UTC, the UTC time is calculated by subtraction. When the timezone is behind (-) UTC, the UTC time is calculated by addition.
For example:

• if your timezone is UTC+1, append +01:00. When you send 2022-10-14T15:00:000+01:00, it is saved in the database as 2022-10-14T14:00:000Z
• if your timezone is UTC-8, append -08:00. When you send 2022-10-14T22:00:000-08:00, it is saved in the database as 2022-10-15T06:00:000Z (note that the date also changes between timezones in this example)

IMPORTANT: If you send an event with a future time, the parameter is rejected and the time of receiving the event is saved as the occurrence time. For example, if your timezone is UTC+1 and you send the event at 15:00 local time, future times are:

• later than 15:00 local time
• later than 14:00 UTC

When you retrieve an event, its time is always shown as UTC. The original time string that you sent (even if it was a future time and was rejected) can be retrieved with the activities endpoints, as snr-original-time.

When an event has an eventSalt, it can be overwritten by sending another event.

eventSalt must be unique in a workspace. An example of creating a salt is by generating a UUID or concatenating the profile ID, event's name, and timestamp, including milliseconds. This creates a value whose possibility of being duplicated is practically zero.

To overwrite an event with another one, the new event MUST:

• have the same eventSalt as the original event
• have the same date and time as the original event (If the date and time don't match the original event, event salt doesn't have any effect.)
• belong to the same clientId as the original event
• have the same action (event name) as the original event

IMPORTANT:

• DO NOT send the same eventSalt to different profiles!
• DO NOT send the same eventSalt with a different action!
• Pay attention to timezones - more details in the description of the time property (in v4/transactions events, it's called recordedAt).
• If you send a future time in an event, it is rejected and the current time is assigned automatically. This means it's impossible to use event salt with future times.
• Overwriting an event by using the event salt doesn't trigger automations.
• An event without an eventSalt can't be overwritten. The parameter cannot be added to an event at a later time.
• The parameter can't be retrieved later. You must keep track of the values that you send.

This parameter is required, but not saved in the database. It can't be used in Analytics, Automations, and so on.

You must provide at least one of those profile identifiers.

Time when the event occurred, in ISO 8601.

This time isn't affected and doesn't affect the timezone of your workspace - you can send events with a timezone different than that of the workspace. Synerise calculates the times into UTC standard when saving events in the database.

If not defined, the backend inserts the time of receiving the event.

A time with a "Z" at the end (for example, 2022-10-14T12:02:06Z) denotes a time in the UTC standard.

If you want to send time in a different timezone, you can do this by appending {+|-}hh:mm at the end of the string.

Note that if the timezone is ahead (+) of UTC, the UTC time is calculated by subtraction. When the timezone is behind (-) UTC, the UTC time is calculated by addition.
For example:

• if your timezone is UTC+1, append +01:00. When you send 2022-10-14T15:00:000+01:00, it is saved in the database as 2022-10-14T14:00:000Z
• if your timezone is UTC-8, append -08:00. When you send 2022-10-14T22:00:000-08:00, it is saved in the database as 2022-10-15T06:00:000Z (note that the date also changes between timezones in this example)

IMPORTANT: If you send an event with a future time, the parameter is rejected and the time of receiving the event is saved as the occurrence time. For example, if your timezone is UTC+1 and you send the event at 15:00 local time, future times are:

• later than 15:00 local time
• later than 14:00 UTC

When you retrieve an event, its time is always shown as UTC. The original time string that you sent (even if it was a future time and was rejected) can be retrieved with the activities endpoints, as snr-original-time.

When an event has an eventSalt, it can be overwritten by sending another event.

eventSalt must be unique in a workspace. An example of creating a salt is by generating a UUID or concatenating the profile ID, event's name, and timestamp, including milliseconds. This creates a value whose possibility of being duplicated is practically zero.

To overwrite an event with another one, the new event MUST:

• have the same eventSalt as the original event
• have the same date and time as the original event (If the date and time don't match the original event, event salt doesn't have any effect.)
• belong to the same clientId as the original event
• have the same action (event name) as the original event

IMPORTANT:

• DO NOT send the same eventSalt to different profiles!
• DO NOT send the same eventSalt with a different action!
• Pay attention to timezones - more details in the description of the time property (in v4/transactions events, it's called recordedAt).
• If you send a future time in an event, it is rejected and the current time is assigned automatically. This means it's impossible to use event salt with future times.
• Overwriting an event by using the event salt doesn't trigger automations.
• An event without an eventSalt can't be overwritten. The parameter cannot be added to an event at a later time.
• The parameter can't be retrieved later. You must keep track of the values that you send.

This parameter is required, but not saved in the database. It can't be used in Analytics, Automations, and so on.

You must provide at least one of those profile identifiers.

Time when the event occurred, in ISO 8601.

This time isn't affected and doesn't affect the timezone of your workspace - you can send events with a timezone different than that of the workspace. Synerise calculates the times into UTC standard when saving events in the database.

If not defined, the backend inserts the time of receiving the event.

A time with a "Z" at the end (for example, 2022-10-14T12:02:06Z) denotes a time in the UTC standard.

If you want to send time in a different timezone, you can do this by appending {+|-}hh:mm at the end of the string.

Note that if the timezone is ahead (+) of UTC, the UTC time is calculated by subtraction. When the timezone is behind (-) UTC, the UTC time is calculated by addition.
For example:

• if your timezone is UTC+1, append +01:00. When you send 2022-10-14T15:00:000+01:00, it is saved in the database as 2022-10-14T14:00:000Z
• if your timezone is UTC-8, append -08:00. When you send 2022-10-14T22:00:000-08:00, it is saved in the database as 2022-10-15T06:00:000Z (note that the date also changes between timezones in this example)

IMPORTANT: If you send an event with a future time, the parameter is rejected and the time of receiving the event is saved as the occurrence time. For example, if your timezone is UTC+1 and you send the event at 15:00 local time, future times are:

• later than 15:00 local time
• later than 14:00 UTC

When you retrieve an event, its time is always shown as UTC. The original time string that you sent (even if it was a future time and was rejected) can be retrieved with the activities endpoints, as snr-original-time.

When an event has an eventSalt, it can be overwritten by sending another event.

eventSalt must be unique in a workspace. An example of creating a salt is by generating a UUID or concatenating the profile ID, event's name, and timestamp, including milliseconds. This creates a value whose possibility of being duplicated is practically zero.

To overwrite an event with another one, the new event MUST:

• have the same eventSalt as the original event
• have the same date and time as the original event (If the date and time don't match the original event, event salt doesn't have any effect.)
• belong to the same clientId as the original event
• have the same action (event name) as the original event

IMPORTANT:

• DO NOT send the same eventSalt to different profiles!
• DO NOT send the same eventSalt with a different action!
• Pay attention to timezones - more details in the description of the time property (in v4/transactions events, it's called recordedAt).
• If you send a future time in an event, it is rejected and the current time is assigned automatically. This means it's impossible to use event salt with future times.
• Overwriting an event by using the event salt doesn't trigger automations.
• An event without an eventSalt can't be overwritten. The parameter cannot be added to an event at a later time.
• The parameter can't be retrieved later. You must keep track of the values that you send.

This parameter is required, but not saved in the database. It can't be used in Analytics, Automations, and so on.

You must provide at least one of those profile identifiers.

Time when the event occurred, in ISO 8601.

This time isn't affected and doesn't affect the timezone of your workspace - you can send events with a timezone different than that of the workspace. Synerise calculates the times into UTC standard when saving events in the database.

If not defined, the backend inserts the time of receiving the event.

A time with a "Z" at the end (for example, 2022-10-14T12:02:06Z) denotes a time in the UTC standard.

If you want to send time in a different timezone, you can do this by appending {+|-}hh:mm at the end of the string.

Note that if the timezone is ahead (+) of UTC, the UTC time is calculated by subtraction. When the timezone is behind (-) UTC, the UTC time is calculated by addition.
For example:

• if your timezone is UTC+1, append +01:00. When you send 2022-10-14T15:00:000+01:00, it is saved in the database as 2022-10-14T14:00:000Z
• if your timezone is UTC-8, append -08:00. When you send 2022-10-14T22:00:000-08:00, it is saved in the database as 2022-10-15T06:00:000Z (note that the date also changes between timezones in this example)

IMPORTANT: If you send an event with a future time, the parameter is rejected and the time of receiving the event is saved as the occurrence time. For example, if your timezone is UTC+1 and you send the event at 15:00 local time, future times are:

• later than 15:00 local time
• later than 14:00 UTC

When you retrieve an event, its time is always shown as UTC. The original time string that you sent (even if it was a future time and was rejected) can be retrieved with the activities endpoints, as snr-original-time.

When an event has an eventSalt, it can be overwritten by sending another event.

eventSalt must be unique in a workspace. An example of creating a salt is by generating a UUID or concatenating the profile ID, event's name, and timestamp, including milliseconds. This creates a value whose possibility of being duplicated is practically zero.

To overwrite an event with another one, the new event MUST:

• have the same eventSalt as the original event
• have the same date and time as the original event (If the date and time don't match the original event, event salt doesn't have any effect.)
• belong to the same clientId as the original event
• have the same action (event name) as the original event

IMPORTANT:

• DO NOT send the same eventSalt to different profiles!
• DO NOT send the same eventSalt with a different action!
• Pay attention to timezones - more details in the description of the time property (in v4/transactions events, it's called recordedAt).
• If you send a future time in an event, it is rejected and the current time is assigned automatically. This means it's impossible to use event salt with future times.
• Overwriting an event by using the event salt doesn't trigger automations.
• An event without an eventSalt can't be overwritten. The parameter cannot be added to an event at a later time.
• The parameter can't be retrieved later. You must keep track of the values that you send.

This parameter is required, but not saved in the database. It can't be used in Analytics, Automations, and so on.

You must provide at least one of those profile identifiers.

Time when the event occurred, in ISO 8601.

This time isn't affected and doesn't affect the timezone of your workspace - you can send events with a timezone different than that of the workspace. Synerise calculates the times into UTC standard when saving events in the database.

If not defined, the backend inserts the time of receiving the event.

A time with a "Z" at the end (for example, 2022-10-14T12:02:06Z) denotes a time in the UTC standard.

If you want to send time in a different timezone, you can do this by appending {+|-}hh:mm at the end of the string.

Note that if the timezone is ahead (+) of UTC, the UTC time is calculated by subtraction. When the timezone is behind (-) UTC, the UTC time is calculated by addition.
For example:

• if your timezone is UTC+1, append +01:00. When you send 2022-10-14T15:00:000+01:00, it is saved in the database as 2022-10-14T14:00:000Z
• if your timezone is UTC-8, append -08:00. When you send 2022-10-14T22:00:000-08:00, it is saved in the database as 2022-10-15T06:00:000Z (note that the date also changes between timezones in this example)

IMPORTANT: If you send an event with a future time, the parameter is rejected and the time of receiving the event is saved as the occurrence time. For example, if your timezone is UTC+1 and you send the event at 15:00 local time, future times are:

• later than 15:00 local time
• later than 14:00 UTC

When you retrieve an event, its time is always shown as UTC. The original time string that you sent (even if it was a future time and was rejected) can be retrieved with the activities endpoints, as snr-original-time.

When an event has an eventSalt, it can be overwritten by sending another event.

eventSalt must be unique in a workspace. An example of creating a salt is by generating a UUID or concatenating the profile ID, event's name, and timestamp, including milliseconds. This creates a value whose possibility of being duplicated is practically zero.

To overwrite an event with another one, the new event MUST:

• have the same eventSalt as the original event
• have the same date and time as the original event (If the date and time don't match the original event, event salt doesn't have any effect.)
• belong to the same clientId as the original event
• have the same action (event name) as the original event

IMPORTANT:

• DO NOT send the same eventSalt to different profiles!
• DO NOT send the same eventSalt with a different action!
• Pay attention to timezones - more details in the description of the time property (in v4/transactions events, it's called recordedAt).
• If you send a future time in an event, it is rejected and the current time is assigned automatically. This means it's impossible to use event salt with future times.
• Overwriting an event by using the event salt doesn't trigger automations.
• An event without an eventSalt can't be overwritten. The parameter cannot be added to an event at a later time.
• The parameter can't be retrieved later. You must keep track of the values that you send.

This parameter is required, but not saved in the database. It can't be used in Analytics, Automations, and so on.

You must provide at least one of those profile identifiers.

Time when the event occurred, in ISO 8601.

This time isn't affected and doesn't affect the timezone of your workspace - you can send events with a timezone different than that of the workspace. Synerise calculates the times into UTC standard when saving events in the database.

If not defined, the backend inserts the time of receiving the event.

A time with a "Z" at the end (for example, 2022-10-14T12:02:06Z) denotes a time in the UTC standard.

If you want to send time in a different timezone, you can do this by appending {+|-}hh:mm at the end of the string.

Note that if the timezone is ahead (+) of UTC, the UTC time is calculated by subtraction. When the timezone is behind (-) UTC, the UTC time is calculated by addition.
For example:

• if your timezone is UTC+1, append +01:00. When you send 2022-10-14T15:00:000+01:00, it is saved in the database as 2022-10-14T14:00:000Z
• if your timezone is UTC-8, append -08:00. When you send 2022-10-14T22:00:000-08:00, it is saved in the database as 2022-10-15T06:00:000Z (note that the date also changes between timezones in this example)

IMPORTANT: If you send an event with a future time, the parameter is rejected and the time of receiving the event is saved as the occurrence time. For example, if your timezone is UTC+1 and you send the event at 15:00 local time, future times are:

• later than 15:00 local time
• later than 14:00 UTC

When you retrieve an event, its time is always shown as UTC. The original time string that you sent (even if it was a future time and was rejected) can be retrieved with the activities endpoints, as snr-original-time.

When an event has an eventSalt, it can be overwritten by sending another event.

eventSalt must be unique in a workspace. An example of creating a salt is by generating a UUID or concatenating the profile ID, event's name, and timestamp, including milliseconds. This creates a value whose possibility of being duplicated is practically zero.

To overwrite an event with another one, the new event MUST:

• have the same eventSalt as the original event
• have the same date and time as the original event (If the date and time don't match the original event, event salt doesn't have any effect.)
• belong to the same clientId as the original event
• have the same action (event name) as the original event

IMPORTANT:

• DO NOT send the same eventSalt to different profiles!
• DO NOT send the same eventSalt with a different action!
• Pay attention to timezones - more details in the description of the time property (in v4/transactions events, it's called recordedAt).
• If you send a future time in an event, it is rejected and the current time is assigned automatically. This means it's impossible to use event salt with future times.
• Overwriting an event by using the event salt doesn't trigger automations.
• An event without an eventSalt can't be overwritten. The parameter cannot be added to an event at a later time.
• The parameter can't be retrieved later. You must keep track of the values that you send.