С чего начинается создание API?

Появилась задача, разделить его на 2 части. Одна для клиентов компании. Другая для работников компании.

Я думаю, что хорошим решением будет это создание API.

Одно к другому вообще никак не ведёт имхо. Как апи решит задачу разделения сайта на две части?
Если там все работает по старинке через "серверный рендеринг", нафига туда впиливать апи и переписывать всё?
Надо сделать для сотрудников отдельную часть, ну так и делайте. Запилили роуты, контроллеры, проверку прав - готово.

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

Вообще отдельная задача, все равно придётся что-то переделывать потом именно под мобильные и т.д.

Я так понимаю, что Вы хотите сместить с чисто серверной логики на случай, когда часть
функционала отдана клиентской части? В этом случае отделяют высокоуровневую логику
в вызовы через API.

Как организовать авторизацию с учетом прав доступа.

Посмотрите библиотеки на PHP по RBAC, если хотите сделать что то сложное. Или
попросту выделите поле role в котором будут admin, manager, ... Про механизм
авторизации, так же, есть OAuth2 для серезного случая или элементарный JWT.
Примеров в интернете полно, поле role помещается в JWT токен. Получив такой
запрос на API с таким токеном в заголовке, сервер проверит подпись и прочитает
поле role и соответственно в обработчике отвегнет запрос или сформирует ответ.
На счет JWT, не забывайте следовать рекомендациям по безопасности.

Как оформляется структура версий. Для каждой версии нужно отдельный проект.

С этим проще. Версионирование важная часть API. Классика: api.site.com/v1/... или
site.com/api/v1/... Далее v2, v3, ... при калечащих изменениях в API

Хочу узнать ваше мнение или совет о том с чего лучше начинать написать. Ранее API не писал. Столько всего нужно переписать, но хотя бы понять с чего

Дело это не простое. Есть литература и доклады с конференции для развития
навыков проектирования API. Для разделения сервера на две части, Вам нужно
определить границы модулей в Вашем текущем сайте. И некоторые модули
вывести отдельным сервисом.

К сожалению, это все хорошо, но если у Вас нет опыта и знании, то Александр Аксентьев
в сухом остатке будет прав. Примером ужасных API полно. Потеряете время или
будете умножать версии, что в итоге плохо.
Разделяйте, когда будете готовы. Лучшим руководством считаю руководства от
дядюшки Боба (Роберт Мартин). Прочитайте книгу "Чистая архитектура",
проведите рефакторинг существующего кода. Когда определятся модули
следующие принципам SOLID, разделение пройдет безболезненно и выбор
формата API облегчится благодаря интерфейсам модулей.

Александр Аксентьев, Я первым делом так и сделал. Разделил сайт. Проблем с этим никаких нет.
Но я просто задумался немного на перед и возникли вопросы.
Как написал Nurbol Suleimenov когда буду готов, буду делать. Отдельное спасибо за литературу.