Data Subject Request API Version 1 and 2
Data Subject Request API Version 3
Platform API Overview
Accounts
Apps
Audiences
Calculated Attributes
Data Points
Feeds
Field Transformations
Services
Users
Workspaces
Warehouse Sync API Overview
Warehouse Sync API Tutorial
Warehouse Sync API Reference
Data Mapping
Warehouse Sync SQL Reference
Warehouse Sync Troubleshooting Guide
ComposeID
Warehouse Sync API v2 Migration
Bulk Profile Deletion API Reference
Calculated Attributes Seeding API
Data Planning API
Custom Access Roles API
Group Identity API Reference
Pixel Service
Profile API
Events API
mParticle JSON Schema Reference
IDSync
AMP SDK
Initialization
Configuration
Network Security Configuration
Event Tracking
User Attributes
IDSync
Screen Events
Commerce Events
Location Tracking
Media
Kits
Application State and Session Management
Data Privacy Controls
Error Tracking
Opt Out
Push Notifications
WebView Integration
Logger
Preventing Blocked HTTP Traffic with CNAME
Linting Data Plans
Troubleshooting the Android SDK
API Reference
Upgrade to Version 5
Cordova Plugin
Identity
Direct URL Routing FAQ
Web
Android
iOS
Initialization
Configuration
Event Tracking
User Attributes
IDSync
Screen Tracking
Commerce Events
Location Tracking
Media
Kits
Application State and Session Management
Data Privacy Controls
Error Tracking
Opt Out
Push Notifications
Webview Integration
Upload Frequency
App Extensions
Preventing Blocked HTTP Traffic with CNAME
Linting Data Plans
Troubleshooting iOS SDK
Social Networks
iOS 14 Guide
iOS 15 FAQ
iOS 16 FAQ
iOS 17 FAQ
iOS 18 FAQ
API Reference
Upgrade to Version 7
Getting Started
Identity
Upload Frequency
Getting Started
Opt Out
Initialize the SDK
Event Tracking
Commerce Tracking
Error Tracking
Screen Tracking
Identity
Location Tracking
Session Management
Initialization
Content Security Policy
Configuration
Event Tracking
User Attributes
IDSync
Page View Tracking
Commerce Events
Location Tracking
Media
Kits
Application State and Session Management
Data Privacy Controls
Error Tracking
Opt Out
Custom Logger
Persistence
Native Web Views
Self-Hosting
Multiple Instances
Web SDK via Google Tag Manager
Preventing Blocked HTTP Traffic with CNAME
Facebook Instant Articles
Troubleshooting the Web SDK
Browser Compatibility
Linting Data Plans
API Reference
Upgrade to Version 2 of the SDK
Getting Started
Identity
Web
Alexa
Overview
Step 1. Create an input
Step 2. Verify your input
Step 3. Set up your output
Step 4. Create a connection
Step 5. Verify your connection
Step 6. Track events
Step 7. Track user data
Step 8. Create a data plan
Step 9. Test your local app
Overview
Step 1. Create an input
Step 2. Verify your input
Step 3. Set up your output
Step 4. Create a connection
Step 5. Verify your connection
Step 6. Track events
Step 7. Track user data
Step 8. Create a data plan
Overview
Step 1. Create an input
Step 2. Verify your input
Step 3. Set up your output
Step 4. Create a connection
Step 5. Verify your connection
Step 6. Track events
Step 7. Track user data
Step 8. Create a data plan
Step 1. Create an input
Step 2. Create an output
Step 3. Verify output
Node SDK
Go SDK
Python SDK
Ruby SDK
Java SDK
Introduction
Outbound Integrations
Firehose Java SDK
Inbound Integrations
Compose ID
Glossary
Data Hosting Locations
Migrate from Segment to mParticle
Migrate from Segment to Client-side mParticle
Migrate from Segment to Server-side mParticle
Segment-to-mParticle Migration Reference
Rules Developer Guide
API Credential Management
The Developer's Guided Journey to mParticle
Create an Input
Start capturing data
Connect an Event Output
Create an Audience
Connect an Audience Output
Transform and Enhance Your Data
The new mParticle Experience
The Overview Map
Introduction
Data Retention
Connections
Activity
Live Stream
Data Filter
Rules
Tiered Events
mParticle Users and Roles
Analytics Free Trial
Troubleshooting mParticle
Usage metering for value-based pricing (VBP)
Introduction
Sync and Activate Analytics User Segments in mParticle
User Segment Activation
Welcome Page Announcements
Project Settings
Roles and Teammates
Organization Settings
Global Project Filters
Portfolio Analytics
Analytics Data Manager Overview
Events
Event Properties
User Properties
Revenue Mapping
Export Data
UTM Guide
Data Dictionary
Query Builder Overview
Modify Filters With And/Or Clauses
Query-time Sampling
Query Notes
Filter Where Clauses
Event vs. User Properties
Group By Clauses
Annotations
Cross-tool Compatibility
Apply All for Filter Where Clauses
Date Range and Time Settings Overview
Understanding the Screen View Event
Analyses Introduction
Getting Started
Visualization Options
For Clauses
Date Range and Time Settings
Calculator
Numerical Settings
Assisted Analysis
Properties Explorer
Frequency in Segmentation
Trends in Segmentation
Did [not] Perform Clauses
Cumulative vs. Non-Cumulative Analysis in Segmentation
Total Count of vs. Users Who Performed
Save Your Segmentation Analysis
Export Results in Segmentation
Explore Users from Segmentation
Getting Started with Funnels
Group By Settings
Conversion Window
Tracking Properties
Date Range and Time Settings
Visualization Options
Interpreting a Funnel Analysis
Group By
Filters
Conversion over Time
Conversion Order
Trends
Funnel Direction
Multi-path Funnels
Analyze as Cohort from Funnel
Save a Funnel Analysis
Explore Users from a Funnel
Export Results from a Funnel
Saved Analyses
Manage Analyses in Dashboards
Dashboards––Getting Started
Manage Dashboards
Dashboard Filters
Organize Dashboards
Scheduled Reports
Favorites
Time and Interval Settings in Dashboards
Query Notes in Dashboards
User Aliasing
The Demo Environment
Keyboard Shortcuts
Analytics for Marketers
Analytics for Product Managers
Compare Conversion Across Acquisition Sources
Analyze Product Feature Usage
Identify Points of User Friction
Time-based Subscription Analysis
Dashboard Tips and Tricks
Understand Product Stickiness
Optimize User Flow with A/B Testing
User Segments
IDSync Overview
Use Cases for IDSync
Components of IDSync
Store and Organize User Data
Identify Users
Default IDSync Configuration
Profile Conversion Strategy
Profile Link Strategy
Profile Isolation Strategy
Best Match Strategy
Aliasing
Overview
Create and Manage Group Definitions
Introduction
Catalog
Live Stream
Data Plans
Blocked Data Backfill Guide
Predictive Attributes Overview
Create Predictive Attributes
Assess and Troubleshoot Predictions
Use Predictive Attributes in Campaigns
Predictive Audiences Overview
Using Predictive Audiences
Introduction
Profiles
Warehouse Sync
Data Privacy Controls
Data Subject Requests
Default Service Limits
Feeds
Cross-Account Audience Sharing
Approved Sub-Processors
Import Data with CSV Files
CSV File Reference
Glossary
Video Index
Single Sign-On (SSO)
Setup Examples
Introduction
Introduction
Introduction
Rudderstack
Google Tag Manager
Segment
Advanced Data Warehouse Settings
AWS Kinesis (Snowplow)
AWS Redshift (Define Your Own Schema)
AWS S3 Integration (Define Your Own Schema)
AWS S3 (Snowplow Schema)
BigQuery (Snowplow Schema)
BigQuery Firebase Schema
BigQuery (Define Your Own Schema)
GCP BigQuery Export
Snowflake (Snowplow Schema)
Snowplow Schema Overview
Snowflake (Define Your Own Schema)
Aliasing
Use the Field Transformations API to create and manage one-to-one correlations, called mappings, between external data and fields in the mParticle JSON schema.
Field transformations are JSON formatted schemas that contain one or more mappings between external source fields and internal mParticle destination fields. Field transformations are identified in the mParticle system by a unique string ID
and string name
.
Each field transformation includes an array called mappings
. This array contains a list of individual mapping objects that specify how external data should be mapped to internal mParticle fields.
{
"id": "unique-string-id",
"name": "Example Field Transformation Name",
"destination_type": "event_batch",
"mappings": [
{
"mapping_type": "mapping-type",
"source": "external-field",
"destination": "destination-field"
}
]
}
Property | Data type | Required | Description |
---|---|---|---|
id |
string | Yes | Unique ID you must set when creating a field transformation. Can only include numbers, letters, dashes - , and underscores _ . |
name |
string | Yes | Descriptive name you must set when creating a field transformation. There are no character restrictions. |
destination_type |
string | Yes | Specifies the type of data being ingested. Valid values include: event_batch |
mappings |
array | Yes | An array of JSON objects that specify which mParticle fields to map source fields to. See Mappings overview for more details. |
Each object in the mappings
array is configured with the following properties:
Property | Required | Description |
---|---|---|
mapping_type |
Yes | Valid values include column , static , ignore . See Mapping type settings for more details. |
source |
Required when mapping_type is column or ignore |
The name of the field in the source data table. This must be left unset or set to null if mapping_type is set to static . |
destination |
Required when mapping_type is column or static |
The name of the mParticle field as it is listed in the mParticle JSON schema. Use the JSON path format when setting the destination field. destination must be unset or set to null for ignore mappings. |
ignore_when |
Optional | Valid values include $null and $empty . When mapping_type is set to column , you can set ignore_when to $null or $empty to ignore a mapping when the external field value is null or empty. If ignore_when is not set, the field value will map null values if supported. |
value |
|
When mapping_type is set to static , you can set value to any string you want to map to an mParticle field, excluding the use of a template. If mapping_type is set to column , you may use a template when setting value . |
value_type |
Optional | The type of data supplied for value . Valid values include string , number , integer , and boolean . |
The supported values for mapping_type
are:
Mapping type | Description |
---|---|
column |
Maps a column in a source database or table to an mParticle field. |
static |
Maps a static value to an mParticle field. source must be excluded, or set to null for static mappings. |
ignore |
Prevents source data from being mapped to mParticle. |
Following are descriptions and examples for each type:
Set mapping_type
to column
to map the values stored in a column in a data table to an mParticle field:
{
"mapping_type": "column",
"source": "source-column-name",
"destination": "mparticle-destination"
}
You can use the column
mapping type to map nested fields within an object in your source data to a destination in mParticle. For example, imagine the following source data stored in a column named "foo"
:
{
"object": {
"property": {
"item": "bar"
}
}
}
You could select the nested field "item"
using:
{
"mapping_type": "column",
"source": "foo.object.property.item",
"destination": "mparticle-destination"
}
This would result in the following output:
{
"mparticle-destination": "bar"
}
You can ignore individual fields when they are empty or null using the ignore_when
setting for column
mappings:
Ignore when empty:
{
"mapping_type": "column",
"source": "source-column-name",
"destination": "mparticle-destination",
"ignore_when": "$empty"
}
Ignore when null:
{
"mapping_type": "column",
"source": "source-column-name",
"destination": "mparticle-destination",
"ignore_when": "$null"
}
Set mapping_type
to static
to map the value of value
to an mParticle field:
{
"mapping_type": "static",
"destination": "mparticle-destination",
"value": "some-value"
}
Set mapping_type
to ignore
to ignore the data listed in source
:
{
"mapping_type": "ignore",
"source": "source-data-to-ignore"
}
To map multiple fields to a single array in mParticle, create a separate mapping for each field.
Within each mapping:
mapping_type
to column
or static
source
to the name of the field or column in your source data. You may use *
as a wildcard selector for field names that share a common prefix.destination
to the name of the destination array in mParticle that you want to map to, including square brackets []
. For example: myArray[]
value
to either a static value if you used the static
mapping type or a template if you want to modify the output of your mapping.Consider the following table of source data where each column name shares the prefix favorite_store_
:
favorite_store_1 | favorite_store_2 | favorite_store_3 |
---|---|---|
target | old navy | walmart |
We can use the wildcard selector *
to map each column to an array in mParticle called favorite_stores[]
:
{
"mapping_type": "column",
"source": "favorite_store_*",
"destination": "user_attribute.favorite_stores[]",
"value": "{{ value | upcase }}"
}
Consider the following table of source data where each column has a unique name:
groceries | clothing | hardware |
---|---|---|
target | old navy | home depot |
To map each of these columns to the array favorite_stores[]
, we create a separate mapping for each element:
[
{
"mapping_type": "column",
"source": "groceries",
"destination": "user_attribute.favorite_stores[]",
"value": "{{ value | upcase }}"
},
{
"mapping_type": "column",
"source": "clothing",
"destination": "user_attribute.favorite_stores[]",
"value": "{{ value | upcase }}"
},
{
"mapping_type": "column",
"source": "hardware",
"destination": "user_attribute.favorite_stores[]",
"value": "{{ value | upcase }}"
}
]
You can create a “default” mapping that will be used for any source data that is not already mapped or ignored by setting source
to the reserved keyword $unmapped
:
{
"mapping_type": "column",
"source": "$unmapped",
"destination": "mparticle-destination"
}
By creating an “unmapped” mapping you can decrease the chances of a warehouse sync pipeline dropping or missing data during ingest.
The mParticle JSON schema defines the structure that must be applied to all event data and user data for it to be ingested and usable by mParticle products.
At the highest level, the mParticle JSON schema contains an events
array which represents an event batch. Each object in the events
batch represents a single event, and it includes the event data stored in an object called data
and the type of event that was logged, or the event_type
. The specific event details are then stored in a series of nested JSON objects.
The Field Transformations API uses a simplified path format when mapping external data with individual fields contained in the mParticle JSON schema:
Top level elements are referred to by their field names:
a
in {"a": 123}
, use a
Nested elements are seperated by .
:
b
in {"a": {"b": 123}}
use a.b
Fields of objects in nested in arrays are referenced using array indices:
b
in {"a": [{"b": 123}]}
use a[].b
mParticle supports the use of Liquid templates with field transformations to enable more flexible and dynamic mappings between your source data and mParticle fields.
Liquid templates can used when setting the value
and destination
fields of a mapping simply by adding the curly brace delimiters {{ }}
surrounding your template object, or variable, and filters. For example:
"value": {{ value }}
You can use filters to modify the output of a template by adding a pipe character |
before the filter:
"value": {{ value | upcase }}
You can string multiple filters together, separating each filter with a new pipe character:
{{ value | upcase | rstrip }}
You can also use the source field name in templates. For example, you can use a template to trim text from a source field name with:
some_prefix_{{ key | remove: "text-to-remove" }}
mParticle supports the following variables for use in templates:
value
: equals value of a field as found in your source databasekey
: equals the name of the column or property containing the value in your source databasekey_length
: equals the number of characters in key
For example, consider the following source data:
favorite_store_1 | favorite_store_2 | favorite_store_3 |
---|---|---|
“target” | “old navy” | “walmart” |
We could map each favorite store to an array in mParticle called favorite_stores
with the mapping:
{
"mapping_type": "column",
"source": "favorite_store_*",
"destination": "user_attribute.favorite_stores[]"
}
Note that this mapping makes use of the wildcard selector *
for source
to select every column name in our source data table that begins with "favorite_store_"
.
The resulting output of this mapping would be:
{
"user_attributes":
{
"favorite_stores": ["target", "old navy", "walmart"]
}
}
However, we can modify the output by setting a template with the upcase
filter to the value of the value
field in our mapping:
{
"mapping_type": "column",
"source": "favorite_store_*",
"destination": "user_attribute.favorite_stores[]",
"value": "{{ $value | upcase }}"
}
The resulting output of this mapping would then be:
{
"user_attributes":
{
"favorite_stores": ["TARGET", "OLD NAVY", "WALMART"]
}
}
You can use templates when setting the destination
of a mapping.
Consider the following example source data:
facebook_id | email_id | twitter_id |
---|---|---|
“johndoe” | “john@example.com” | “@johndoe” |
To map each column to the correct user identity in mParticle, we can use the variable key
with the remove
filter in a template with user_identities
:
{
"mapping_type": "column",
"source": "*_id",
"destination": "user_identities.{{ key | remove: '_id' }}"
}
The resulting output of this mapping would be:
{
"user_identities":
{
"facebook": "johndoe",
"email": "john@example.com",
"twitter": "@johndoe"
}
}
Filters can be used in your template to modify the source data you want to map to an mParticle field. To learn more about a specific filter, refer to Filters in the Liquid documentation.
mParticle supports the following filters for use in templates:
abs
append
at_least
at_most
capitalize
ceil
compact
concat
date
default
divided_by
downcase
first
floor
join
last
lstrip
map
minus
modulo
plus
prepend
remove
remove_first
remove_last
replace
replace_first
replace_last
reverse
round
rstrip
size
slice
sort
sort_natural
split
strip
strip_newlines
sum
times
truncate
truncatewords
uniq
upcase
where
The asterisk *
character can be used as a wildcard when selecting both your source fields and destinations in a mapping.
For example, consider the following data:
favorite_store_1 | favorite_store_2 | favorite_store_3 |
---|---|---|
“target” | “old navy” | “walmart” |
Setting source
in a mapping for this data to favorite_store_*
will select all three columns, since they each share the same prefix favorite_store_
.
The wildcard selector can also function as a shorthand for the more verbose template {{ key }}
when setting the destination. For example, the following mapping will map each store in the source data to a separate field of the same name within the user_attributes
object in mParticle’s JSON schema:
Example mapping:
{
"mapping_type": "column",
"source": "favorite_store_*",
"destination": "user_attributes.favorite_store_*"
}
Example output:
{
"data": {
"user_attributes": {
"favorite_store_1": "target",
"favorite_store_2": "old navy",
"favorite_store_3": "walmart"
}
}
}
Wildcards are also supported when selecting fields nested within an object as your source. For example:
Example source data:
sizes |
---|
{"shoe_size": "12", "pants_size": "medium", "shirt_size": "small"} |
Example mapping:
{
"mapping_type": "column",
"source": "sizes.*_size",
"destination": "user_attributes.custom_attributes.{{ key }}"
}
Example output:
{
"user_attributes": {
"custom_attributes": {
"shoe_size": "12",
"pants_size": "medium",
"shirt_size": "small"
}
}
}
Consider the following simplified example source data table and destination schema:
Example source database table
column names: | eventId | sessionId | timeStamp | eventType | ip | fieldToIgnore | staticValueToMap |
---|---|---|---|---|---|---|---|
data rows: | 1234 | 5678 | 1402521613976 | screen_view | 172.217.12.142 | value-to-ignore | bar |
… | … | … | … | … |
Example destination JSON schema
{
"events": [
{
"data": {
"event_id": 1234,
"session_id": 5678,
"timestamp_unixtime_ms": 1402521613976,
"custom_attributes":
{
"foo": "bar"
}
},
"event_type": "screen_view"
}
],
"source_request_id": "7fa67be4-f83a-429f-9d73-38b660c50825",
"environment": "production",
"mpid": 7346244611012968789,
"ip": "172.217.12.142"
}
A field transformation mapping each attribute in the database table to the attributes as they exist in the mParticle JSON schema would be:
Example field transformation
{
"id": "example-field-transformation-id",
"name": "Example Field Transformation",
"destination_type": "event_batch",
"mappings": [
{
"mapping_type": "column",
"source": "eventId",
"destination": "events[].data.event_id"
},
{
"mapping_type": "column",
"source": "sessionId",
"destination": "events[].data.session_id"
},
{
"mapping_type": "column",
"source": "timeStamp",
"destination": "events[].data.timestamp_unixtime_ms"
},
{
"mapping_type": "column",
"source": "ip",
"destination": "ip"
},
{
"mapping_type": "ignore",
"source": "fieldToIgnore"
},
{
"mapping_type": "static",
"destination": "events[].data.custom_attributes.foo",
"value": "bar"
}
],
"created_on": "2023-11-14T21:15:43.182Z",
"created_by": "developer@example.com",
"last_modified_on": "2023-11-14T21:15:43.182Z",
"last_modified_by": "developer@example.com"
}
The Field Transformations API can be authenticated with a bearer token.
To create a bearer token, send a POST request to mParticle’s SSO token endpoint at https://sso.auth.mparticle.com/oauth/token
.
The JSON body of the request must contain:
client_id
- the client ID, issued by mParticle when creating the API credentialsclient_secret
- the client secret, issued by mParticle when creating the API credentialsaudience
- set to a value of "https://api.mparticle.com"
grant_type
- set to a value of "client_credentials"
curl --request POST \
--url https://sso.auth.mparticle.com/oauth/token \
--header 'content-type: application/json' \
--data '{"client_id":"...","client_secret":"...","audience":"https://api.mparticle.com","grant_type":"client_credentials"}'
POST /oauth/token HTTP/1.1
Host: sso.auth.mparticle.com
Content-Type: application/json
{
"client_id": "your_client_id",
"client_secret": "your_client_secret",
"audience": "https://api.mparticle.com",
"grant_type": "client_credentials"
}
A successful POST request to the token endpoint results in a JSON response as follows:
{
"access_token": "YWIxMjdi883GHBBDnjsdKAJQxNjdjYUUJABbg6hdI.8V6HhxW-",
"expires_in" : 28800,
"token_type": "Bearer"
}
Subsequent requests to the API can then be authorized by setting the authorization header to:
Authorization: Bearer YWIxMjdi883GHBBDnjsdKAJQxNjdjYUUJABbg6hdI.8V6HhxW-
Tokens cannot be revoked, but they expire every eight hours. The initial token request can take between one and three seconds, so mParticle recommends that you cache the token and refresh it only when necessary.
GET
https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields
Path Parameter | Type | Description |
---|---|---|
{workspaceId} |
Integer | The ID for the workspace containing field transformations you want to retrieve. |
Query Parameter | Type | Description |
---|---|---|
{destinationType} |
String | Valid value: event_batch . |
curl --location --request GET 'https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields' \
--header 'Authorization: Bearer <access_token>'
No request body.
A successful request receives a 200
response with an array containing each field transformation within a JSON object.
[
{
"id": "string",
"name": "string",
"destination_type": "event_batch",
"mappings": [
{
"mapping_type": "column",
"source": "string",
"destination": "string",
"value": "string"
}
],
"created_on": "2023-11-14T21:12:36.246Z",
"created_by": "string",
"last_modified_on": "2023-11-14T21:12:36.246Z",
"last_modified_by": "string"
}
]
POST
https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields
curl --location --request POST 'https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields' \
--header 'Authorization: Bearer <access_token>'
{
"id": "string",
"name": "string",
"destination_type": "event_batch",
"mappings": [
{
"mapping_type": "column",
"source": "string",
"destination": "string",
"value": "string"
}
],
"created_on": "2023-11-14T21:15:43.182Z",
"created_by": "string",
"last_modified_on": "2023-11-14T21:15:43.182Z",
"last_modified_by": "string"
}
A successful request receives a 200
response with a JSON object containing the field transformation you just created.
{
"id": "string",
"name": "string",
"destination_type": "event_batch",
"mappings": [
{
"mapping_type": "column",
"source": "string",
"destination": "string",
"value": "string"
}
],
"created_on": "2023-11-14T21:15:43.182Z",
"created_by": "string",
"last_modified_on": "2023-11-14T21:15:43.182Z",
"last_modified_by": "string"
}
GET
https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields/{fieldTransformationId}
Path Parameter | Type | Description |
---|---|---|
{workspaceId} |
Integer | The ID for the workspace containing the field transformation. |
{fieldTransformationId} |
Integer | The ID for the field transformation you want to retrieve. |
curl --location --request GET 'https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields/{fieldTransformationId}' \
--header 'Authorization: Bearer <access_token>'
No request body.
A successful request receives a 200
response with a JSON object containing the field transformation.
{
"id": "string",
"name": "string",
"destination_type": "event_batch",
"mappings": [
{
"mapping_type": "column",
"source": "string",
"destination": "string",
"value": "string"
}
],
"created_on": "2023-11-14T21:24:26.511Z",
"created_by": "string",
"last_modified_on": "2023-11-14T21:24:26.511Z",
"last_modified_by": "string"
}
PUT
https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields/{fieldTransformationId}
Path Parameter | Type | Description |
---|---|---|
{workspaceId} |
Integer | The ID for the workspace containing the field transformation. |
{fieldTransformationId} |
Integer | The ID for the field transformation you want to update. |
curl --location --request PUT 'https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields/{fieldTransformationId}' \
--header 'Authorization: Bearer <access_token>'
{
"id": "string",
"name": "string",
"destination_type": "event_batch",
"mappings": [
{
"mapping_type": "column",
"source": "string",
"destination": "string",
"value": "string"
}
]
}
A successful request receives a 200
response with a JSON object containing the updated field transformation.
{
"id": "string",
"name": "string",
"destination_type": "event_batch",
"mappings": [
{
"mapping_type": "column",
"source": "string",
"destination": "string",
"value": "string"
}
],
"created_on": "2023-11-14T21:25:50.947Z",
"created_by": "string",
"last_modified_on": "2023-11-14T21:25:50.947Z",
"last_modified_by": "string"
}
DELETE
https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields/{fieldTransformationId}
Path Parameter | Type | Description |
---|---|---|
{workspaceId} |
Integer | The ID for the workspace containing the field transformation. |
{fieldTransformationId} |
Integer | The ID for the field transformation you want to delete. |
curl --location --request DELETE 'https://api.mparticle.com/platform/v2/workspaces/{workspaceId}/transformations/fields/{fieldTransformationId}' \
--header 'Authorization: Bearer <access_token>'
No request body.
A successful request receives a 204
response with an empty body.
Response code | Error message | Description |
---|---|---|
400 | Bad Request | |
401 | Unauthorized | Verify that you have created the correct API credentials for the Field Transformations API and that you are using the correct authentication method. |
403 | Forbidden | Verify that you have created the correct API credentials for the Field Transformations API and that you are using the correct authentication method. |
404 | Not Found |
Was this page helpful?