_ _

По-моему интеграционное тестирование API снаружи это последнее, чем надо заниматься. Протестировать отдельно API юнит-тестом, мокнув сервис отправки почты, чтобы он в массив отправленные письма складывал и отдельно сам сервис почты.

Firebase, например. Раньше для такого использовали parse, а сейчас на firebase пересели

Правильно вам ответил DevMan - ограничение количества запросов, синтетическое увеличение времени ответа сервера при подозрительной активности. В основном все упирается в поведенческий анализ - если кто-то (IP-адрес или можно поискать библиотеки для более сложной эвристики определения уникальных пользователей) целенаправленно стучится по одному и тому же API endpoint, перебирая параметр пагинации, то вас, скорей всего, парсят - ставим этот IP-адрес в список подозрительных и добавляем ему синтетическую задержку ответа в 3 секунды и лимит одновременных соединений. А если он настойчивый, то и вовсе баним

Как насчет webview и в нем окошко jivochat запилить?

"Вам нужно использовать jQuery" (c)

REST это всего лишь соглашение. Точно так же, как соглашение об именовании переменных или соглашение о сигнатуре callback-функций в nodejs.
REST может сделать вашу жизнь легче, а также позволит вам использовать клиентские наработки, ориентированные на работу с REST-style API.
Сам по себе API подразумевает всего лишь возврат данных в машиночитаемом формате (ну и некий документированный набор входных данных, конечно), потому что API это Application Programming Interface, т.е. средство, позволяющее взаимодействовать с вашей разработкой сторонним приложениям.
Например, GET mysite.ru/news/article.html - вероятно не метод API, потому что скорей всего вернет уже оформленный html
GET mysite.ru/news/article.json - вероятно метод API, потому что скорей всего вернет данные статьи в JSON
.html и .json тут для наглядности, можно и через хэдер сказать серверу, какой тип контента тебе нужен.

Elixir. Фана куча. У меня от Go было чувство, как будто лимон сожрал, а тут прямо все здорово.
Вроде и эрланг, но вроде и по-человечески все.

Вам в ответе выше посоветовали slate, но как по мне - писать всю документацию руками в markdown это какое-то садо-мазо.
Есть apiDoc, который генерирует документацию из специальным образом размеченных комментариев в вашем коде.

А вам какого уровня сложности?
Это можно сделать с помощью:
- VanillaJS
- jQuery
- Ember
- AngularJS
...тут еще с десяток разнообразных поделок.

У каждого из способов свои плюсы и минусы, свой порог вхождения.

Логи запросов писать в Elasticsearch

Я бы сделал вариант Б.
Недостаток варианта А - плохо согласуется с REST и надо допиливать сервер.
Недостаток варианта В - подходит, только если дочерних элементов немного, и надо допиливать сервер.

Но тогда о преимуществе в скорости над существующими проектами уже не поговорить

Над какими "существующими проектами"? У вас производительность упрется в базу данных гораздо раньше, чем в технологию. Уже сто раз это обсасывали.

Все перечисленные вами варианты имеют право на существование:
- и обращение к RESTful сервису со стороны сервера, дабы получить нужную информацию и сформировать из нее статический html
- и обращение к RESTful сервису непосредственно из браузерного скрипта, который самостоятельно будет визуализировать полученные данные

Но важно понять следующее - когда у вас есть RESTful-сервис, к нему могут обращаться серверы, браузерные Single Page Javascript Applications, мобильные приложения, и даже десктопные клиенты, в то время как обычный сайт ориентирован только на доставку HTML-контента, сгенерированного на стороне сервера, и любая интеграция, которая органично выполняется при налиии RESTful-сервиса, выливается в дополнительную головную боль.

Что значит "проект"? Мобильное приложение? Сайт?
API у них само собой никакого нет, но есть оракл. Подключаетесь к базе и выставляете наружу нужную информацию.

Можно написать swagger-документацию или сделать ее автогенерацию.