Skip to main content

Webservices related to Profiles

The notion of 'Profiles' in Actito allows you to manage tables of data towards which communication will be possible. For example, a 'profile' is a customer, a prospect, a partner,... who can receive a communication through an 'interaction' channel in Actito (e-mail, SMS, print campaign,...)

These profile tables are structured by means of 3 kinds of data :

  • attributes
  • subscriptions
  • segmentations

For additional information regarding the set up of your profile database and its components, we invite you to read the chapter dedicated to 'Profiles'.

Profile APIs​

Profile APIs give you the possibility to:

Creating your profile table is usually done at the set-up of your license by the Actito team, as it directly tied to the other tables of your data model. It is also possible create it directly in the interface. Keep in mind that modifying the structure of your profile table will usually also require you to update the definition of your synchronizations (see below).

tip

We advise this table to be populated by at least 1 profile, in order to ease up the implementation of APIs. This will indeed allow to easily identify the table structure and, especially, all elements expected to parameter the attributes, subscriptions and segmentations which make up a profile.

Creating or updating a profile​

Once you know the structure of a profile table, it is possible to populate it directly through the Actito webservices.

The Actito APIs allow to ways to create of update profiles in a database: one by one or in bulk. Choosing between these two processes must be based both on the requirements of your own business activity but also on the limits regulating the use of webservices.

You should therefore ask yourself the following questions:

  • Is real-time synchronization necessary?
  • Do you need to trigger real-time scenarios?
  • Which volume are you handling?
  • Is your preferred method compatible with the call limitations?

Bulk APIs must be used when data can be accumulated until reaching a volume large enough for batch processing. The mass import API method is not meant to repeatedly post light files containing only a few records. There is indeed a limitation of 12 bulk calls per day. Moreover, mass imports are asynchronous. Posting several files at once is not an accepted practice, as they will be taken into account one after the other.

On the other hand, when the data is designed to trigger a workflow or must be immediately synchronized with the database, you should opt for one by one calls.

Should the specificities of your activity require a mix of real-time synchronization and daily synchronization, we advise you to divide your calls between mass imports and one by one calls on a case by case basis depending on the volume and immediacy required.

Step by step Use Case​

To get an overview of the process of importing custom table records one by one or in bulk, follow the Profile tables synchronization use case on the Developers Portal!