This is an internal API used by PBX servers.

It is invoked when a recording has completed and the employee who owns the recording wants to receive it via e-mail. The e-mail is sent to the employees own e-mail address.

The e-mail has the same content as the E-mail endpoint - in this order, and only when present on the recording:

1. A warning box at the top when the AI sensitivity level is not NORMAL.
2. The AI summary, formatted for easy reading.
3. The calendar events found by the AI, each with an “add to Google Calendar” link and attached to the e-mail as an .ics calendar file.
4. The sensitivity level and the reasons the AI chose it, when the level is not NORMAL.
5. The recording attached as MP3 - only when the employees recording notification settings ask for attachments (recording.notification.attach) and the estimated file size is within recording.notification.maxSize - otherwise a link to the portal. With 0 days retention see below.
6. The transcription, folded and expanded by the click of a button (e-mail clients without support for folding show it expanded).

The e-mail is written in the employees language (Danish or English).

When the employee keeps recordings 0 days (recording.retension = 0, see Employee update), the e-mail is the only copy of the recording:

• The recording is always attached, whatever recording.notification.attach says - as long as its size is within recording.notification.maxSize and the mail servers limit. When it is too large, the e-mail says the recording was too large to attach and has been deleted, instead of linking to the portal.
• Once the e-mail has been sent, the recording is deleted - the audio file and the recording with its transcription and AI summary. The response then has deleted set to true.
• When the e-mail cannot be sent nothing is deleted. Recordings left over this way are removed by the nightly clean-up one day after they were made.

When the owner of the recording has automatic transcription enabled (recording.transcribe is not DISABLED), this endpoint does not send the e-mail before the transcription and the AI summary are stored on the recording. Without that wait the e-mail is rendered without them, as the PBX invokes Transcribe auto and this endpoint as two independent requests.

• When another request is already transcribing the recording, it waits for that request - up to 3 minutes - and then uses what it stored. See pbxRecordingTranscribe.
• When nothing has transcribed the recording yet, it transcribes and summarizes the recording itself.
• When the transcription fails, or the wait runs out, the e-mail is sent without the summary and transcription rather than not at all.

The request may therefore take minutes to reply - far longer than the PBX HTTP timeout. That is harmless: the e-mail is sent whether or not the PBX is still waiting for the reply. A PBX retry does not send a second e-mail - the recording is claimed in pbxRecordingEmailSent for 15 minutes and the retry replies with sent set to false.

https://api.telecomx.dk/pbx/recording/1234578901234567890ABCD/send

{
  "success": true,
  "sent": true,
  "deleted": false
}