NUACOM API

Calls

Call Notes

Call notes are free-text remarks attached to a call, with the user who wrote them and when. A call can hold any number of notes; they appear in the call details, go to the account's connected CRM integrations and fire the note_added webhook. This group holds one reading endpoint and two identical ways of adding a note. Call rows carry their notes in extra.call_notes (see Call Logs); rules that make a note mandatory after a call are in After Call Work.

Workflow (what the portal does)

  1. Read the notes of a call: GET /v2/call-notes?callIDs[]=…. callIDs is an array (callIDs[]=a&callIDs[]=b) or one comma-separated string; pass the row's call_id, sip_call_id and original_sip_call_id together, because a note is stored under whichever of them was used to add it. The answer is an array, newest first, of call_id (the id the note was stored under), note, account_id, user_id, user_name (null when that user no longer exists) and note_time (ISO 8601, UTC). Ids of several calls can be mixed in one request; tell the notes apart by call_id. Without callIDs the endpoint answers 406 with the body false.
  2. Add a note: POST /v3/call-notes with callId (a string of up to 100 characters: the row's call_id, sip_call_id or original_sip_call_id) and note (up to 1000 characters; HTML tags are stripped). Answers 204. POST /v2/call-notes is the same operation under its older path; both stay available and behave identically.
  3. What follows: the note is stored with the calling user as its author, the account's CRM integrations receive the updated call, and a note_added webhook goes to the subscribed URLs (see Integrations).
# Add a note
curl -X POST https://api.api-nuacom.com/v3/call-notes \
  -H 'Authorization: Bearer YOUR_API_KEY' -H 'Content-Type: application/json' \
  -d '{"callId":"1761640800.123","note":"Customer asked for a quote by Friday"}'
# → 204

# Read the notes back; repeat callIDs[] for the row's sip_call_id and original_sip_call_id
curl 'https://api.api-nuacom.com/v2/call-notes?callIDs[]=1761640800.123' \
  -H 'Authorization: Bearer YOUR_API_KEY'
# → [{"call_id":"1761640800.123","note":"Customer asked for a quote by Friday","account_id":"IE-00123","user_id":123,"user_name":"Jane","note_time":"2026-10-28T09:15:00.000000Z"}]

Roles and access

  • Any authenticated user can read and add notes; nothing in this group is admin-only.
  • Notes are scoped to the account, not to the user's call-log permissions: GET /v2/call-notes answers the notes of any call of the account whose ids you pass, and POST accepts any call of the account. A call of another account, or an id that matches no call, is refused with 422 ("The given call does not belong to this account.").

Pitfalls

  • callId must be a JSON string: a bare number such as 1761640800.123 fails validation (422).
  • Store notes under the row's call_id when you can; whichever id you use, read them back with all three ids, as the portal does.
  • The missing-parameter answer of GET /v2/call-notes is 406, not 422, and its body is false.
  • The text is stored with its HTML tags removed, silently; it is not truncated: more than 1000 characters answers 422.
  • Editing and deleting a note is not part of this group; the portal does both in the browser.
  • note_time is set by the server. In GET /v2/call-notes it is ISO 8601 in UTC; inside a call row (extra.call_notes) it follows the row's date format, which the account's ISO dates option decides.
  • user_name is the user behind the token. With an API key that is the admin who created the key, not your end user; put the author in the text when it matters.