Skip to end of metadata
Go to start of metadata

Last Updated: Tuesday, February 25, 2020


A Person entity is an identified entity that has interacted with or been loaded into the Mobile Database. It is identified by a person_key, which uniquely identifies the record, or an external_person_id, which is a unique identifier from the customer system for reference and cross-linking.

A Person can also be tracked/linked by a Mobile Directory Number (MDN). This alternate identifier is sufficient in the short-term, but it is not an ideal long-term identification method because mobile numbers can be changed, returned, ported, and recycled.

Topics in this Section

Note: If you are using Version 2 of the APIs, a mobile number must use the E.164 format. E.164 is the official format for all international phone numbers that includes a plus sign followed by the country code and phone number.

For example:

  • U.S.: +12135551234
  • U.K.: +442135551234

Associating Person Records

Because of the dynamic nature of mobile participation and campaigns, it is possible that Person records could exist in either the Mobile Database or the Customer system in any sequence/order. The following logic ensures that if the records exist in more than one place, the same Person entity gets tied together to avoid inadvertently linking two different people:

  1. The person_key and external_person_id columns are always treated as the same Person record and must be unique (the external_person_id can be omitted if it is not used/exist).
  2. If the MDN and carrier_code match an existing Person record, they will be considered the same Person entity. If the carrier_code does not match, then they will be assumed to be different people.
Note: Since phone numbers often get ported and/or recycled, and to ensure Mobile Marketing Association (MMA) compliance, it is not a valid assumption that carrier changes are made to the same Person.

Person Entity

The following is the JSON representation of a Person entity within the APIs.

Note: The following example is of Version 2 of the APIs that uses the E.164 international MDN format. If you are using Version 1 of the API, you cannot use the E.164 format.

            "name":"My Hardware Store"
            "name":"Local Grocery"


Data Element



person_idStringDEPRECATED This value is not used and will be removed in future API versions.



Vibes unique identifier for each Person record in the Mobile Database.



Customer unique identifier for a Person in the Mobile Database. This value is optional, but if specified, must be unique within the Mobile Database.  This value can only be up to 50 characters long. 

Person identifiers that are canonical in external systems can be assigned to Person resources in the "external_person_id" field. Any string value can be assigned as the external person id. If the external_person_id value contains non-URL-safe characters, they must be encoded if used in the URL.



Object representation of a Person's mobile phone. A Person can have only one active Mobile Phone at a time.



The Mobile Directory Number (a number that can be dialed).

If you are using Version 1 of the APIs, do not use the E.164 MDN format.

If you are using Version 2 of the APIs, It must be in E.164 format, for example: +12195551234.



The Cellular Carrier associated with this mobile number.



Additional Field Types like String, Date, Single-Selection, and Multi-Selection.

Custom Field Types

Field Type

Value Representation


 Value: String

 To clear a String custom field of its value, send null.


Value: Date. It should be in the ISO 8601 format - for example: 2017-01-05T14:30Z.

 To clear a date custom field of its value, send null.


Object with :id and :name.


An array of Objects, with each Object having the content of a Single Select.

  • No labels


  1. Custom fields are marked as an Object because there is NO intent/use cases to where a caller needs to know dynamically the type of a field,and thus we will not be including it. In the case where a dynamic field parser is needed, that process can make a call to get custom fields which can contain all of that information. It will not be included within the Person object.

  2. Should we use machine friendly keys in the custom fields object? i.e. "first_name" instead of "First Name".

    1. Yes, we should. and yes we will.