Upsert user preferences

Batch-upsert preference records for multiple users.

Rate Limits

• 10000 preference records per organization per minute (default).
• This limit can be adjusted per organization upon request.

Note: Unlike other Preferences API endpoints, the upsert preferences endpoint has a default rate limit of 10,000 preference records per organization per minute, not 10,000 requests per minute. This means that you can update up to 10,000 preference records in batches of any size (up to 100 records per batch) within a minute. For example, you could update 100 records in a single request, or 10 records in each of 10 requests, and both would consume the same portion of your rate limit (100 records).

Rate Limiting Headers

• X-RateLimit-Limit: The maximum number of requests allowed in the current window.
• X-RateLimit-Remaining: The number of requests remaining in the current window.
• X-RateLimit-Reset: The time at which the current rate limit window resets in ISO 8601 format.
• Retry-After: (on 429) The number of seconds to wait before making a new request.

Transcend ID (Record Lookup by Stable Identifier)

• Every preference record has a system-managed transcend identifier — a stable UUID automatically assigned by the system.
• Use { "name": "transcend", "value": "<uuid>" } in the identifiers array to look up and update an existing record.
• Transcend ID is returned in all successful responses alongside other identifiers.
• You cannot create a new record using only a transcend identifier — it must resolve to an existing record.
• If the UUID does not match any existing record, the affected record is returned in failures with the error: "The transcend identifier in this request does not match any consent profile for this organization."
• The transcend identifier is system-managed and immutable from client mutations.

Per-purpose timestamps

• purposes[].timestamp is optional and must be an ISO 8601 timestamp when provided. If omitted, the purpose falls back to the record-level timestamp.
• The record-level timestamp still reflects the most recent time any purpose on the record changed.
• If a purpose value is unchanged, its stored per-purpose timestamp is preserved even when the request includes a newer record-level timestamp.
• Updating one purpose does not change another purpose's stored timestamp.
• Future timestamps are accepted to tolerate clock drift.
• If an incoming purpose timestamp is older than the stored timestamp for the same purpose, the write succeeds but the newer stored consent value and timestamp are kept.
• For large historical backfills, send sequential PUT requests ordered oldest-first instead of relying on one request to backdate multiple purposes with conflicting times.

Source system (audit tagging)

• purposes[].sourceSystem is optional. When provided, it tags the purpose update with the external system that made the change (for example, a CRM or marketing automation platform).
• Useful for automated consent updates where you want an audit trail of where each change originated.
• When omitted, no source system is recorded for that purpose update.