Most operations wrap their payload in a RestResponse envelope:
The payload you actually want is always under data.

​
Not everything is wrapped

Three groups bypass the envelope, and the payload is the whole response body:
  • GET /api/v1/billing/usage/{period}
  • GET /api/v1/queue-insights/task/{taskId}/summary
  • The four task-monitoring operations, which return their DTO directly
Write your client to tolerate both shapes rather than assuming the envelope.

​
The envelope status can disagree with the HTTP status

status inside the envelope is set by hand at each call site, and it is not always the HTTP status of the response. The clearest example is keyword and webhook creation, which return HTTP 200 while the envelope reports "status": 201. Trust the HTTP status line.

​
Two representations of success, depending on the endpoint

This one causes real bugs. Some acknowledgement payloads carry success as a JSON boolean, others as the string "true". It depends on the map type the handler happened to use, not on anything meaningful.
The calendar delete, sync and test-rule operations use the string form. The inbound message, keyword and webhook operations use the boolean form. A strict JSON client that expects a boolean will fail on the calendar family. Each affected operation’s schema in this reference shows which form it returns, so check the schema rather than generalising from another endpoint.

​
Empty payloads

Five delete operations return the envelope with no data at all, because their handler signature carries no payload type. An absent data on those is success, not a truncated response.