Recording-Server* ids, and they publish on the same all-core-servers channel as a normal entry write, so the whole cluster ends up agreeing about the target's entries.case-id, falling back to device-aor — the same key the row itself uses. Only the client-supplied fields are copied (device-aor, case-id, transcription, sentiment); the interception sentinels are server-set, exactly as on a normal write.202 with a job-id to poll. Validation still happens at request time — a bad id or a non-superuser caller fails here, not silently inside the job. synchronous=yes waits and returns the result inline; a synchronous request with more pending entries than the server's ceiling is handed to the async path instead (202, downgraded-to-async: yes) rather than risking a gateway timeout mid-run.failures.Authorization: Bearer ********************synchronous=yes), or the counts for a dry-run=yes preview. A source with zero entries is a plain 200 with nothing copied, not an error.curl --location 'https://awqacore01.crexendocloud.com/ns-api/v2/recordings/servers//entries/sync' \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '{
"source-recording-server-id": "Recording-Server1",
"synchronous": "no",
"dry-run": "no",
"overwrite-existing": "no"
}'{
"source-recording-server-id": "Recording-Server1",
"recording-server-id": "Recording-Server2",
"source-total": 3975,
"copied": 3563,
"overwritten": 0,
"skipped": 412,
"failed": 0,
"failures": [
{
"device-aor": "sip:1123wp@example.com",
"case-id": "sip:1123wp@example.com",
"message": "service bus publish failed"
}
],
"failures-truncated": "yes",
"processed": 3563,
"total": 3563,
"dry-run": "yes",
"message": "string"
}