Skip to main content

Use Privacy By Design

Sitata has designed its platform with "Privacy By Design" principles and it is possible to integrate Sitata's services without disclosing any customer data to Sitata whatsoever. We accomplish this by allowing you to create records with an associated external_id and then relay various events and information to your platform through our webhook system.

The following guide will walk you through how such a setup could be created to integrate our Alerts and Advisories into your platform without sending customer data to Sitata.

warning

Anonymous travellers require the Whitelabel Travellers package. Requests to create them without it are rejected. For those travellers to receive risk alerts without individual subscriptions, your organization also needs the Managed Alerts package.

Create an Anonymous Traveller

The simplest way to register a privacy-preserving traveller is the dedicated anonymous traveller endpoint. You supply only an external_id that corresponds to an identifier in your own database — no name, email, or other PII is required. Sitata mints a shell record on your behalf, flagged as anonymous, with a generated non-deliverable email and a cosmetic placeholder name.

Issue a POST request against /org/:organization_id/users/anonymous using your organization's authentication token:

{
    "external_id": "<YOUR ID HERE>"
}

The response is a standard user profile with "anonymous": true. Store the returned id alongside your own record so you can create trips and reference the traveller elsewhere in the API.

info

This endpoint is idempotent by external_id. Calling it again with the same external_id returns the existing traveller rather than creating a duplicate, so it is safe to call whenever you sync a customer to Sitata.

External IDs in the Sitata platform are stored as strings and we do not enforce any uniqueness on this field.

Register a Trip in One Step

If you would rather register travellers and their trip together, pass a traveller_external_ids list when creating a trip. For each id, Sitata attaches the trip to the traveller whose external_id matches; if no such traveller exists yet, it mints an anonymous shell record for the id on the fly. Either way, no separate traveller request is needed, and calling it again with the same id reuses the same person.

Receiving Alerts

Finally, create a webhook endpoint to receive alerts and advisories. Anonymous travellers are monitored just like any other traveller, but Sitata never delivers alerts, email, or SMS to them directly — every notification is relayed to your platform through the webhook so that you remain the sole point of contact with the end user. See Deliver Travel Alerts and Advisories for the details.

With all of the above in place, your platform will receive webhook events for any alerts and advisories that might affect your travellers. No customer data has been exchanged. When you receive the webhook data, you can use the external_ids to reference data in your own database before deciding what to do with it.

info

Although we allow for external_ids to be specified, it can still be helpful to store Sitata IDs in your own database to more easily use other portions of our API since many portions of our API still demand Sitata IDs.

Creating Anonymous Records Manually

You do not have to use the dedicated endpoint. You can also create an ordinary user record and simply omit any real PII, providing random values for required unique fields such as email:

{
    "email": "[email protected]",
    "first_name": "Anonymous",
    "last_name": "Anonymous",
    "external_id": "<YOUR ID HERE>"
    // etc...
}
tip

A manually created record is not flagged anonymous, so Sitata's comms suppression does not apply to it. If you want to remain the sole point of contact with the traveller, take care not to supply a reachable email or phone number — provide random values instead (UUIDs work great). The dedicated endpoint above handles all of this for you.