Так. ну во-первых я захожу в репос и вижу дефолтный

readme от симфони, апдгрейд логи и прочую хрень. такое удалять надо.
еще .idea папка должна быть под игнором, иначе такое ощущение что гит ты впервые видишь
gw_data.sql - это должны бить миграции + вспомогательная команда симфони для наполнения данными, либо фикстуры.
bash.exe.stackdump - под виндой что ли?
поехали по сорсам. если тестов нет, то дефолтный тест контроллер тоже удалять нужно. в репосе не должно быть ничего лишнего.
ApiController: во-первых у каждого ресурса должен быть свой контроллер Api/CompaniesController, Api/UsersController. учитывая что это обычный CRUD, который идеально ложиться на REST, то get это должен быть get вместо поста, delete/edit тоже свои методы хттп. да и вообще придерживаться семантики не мешало бы. коды ошибок хттп туда же. везде щас 200я возвращается
самая первая функция с $retData[$retCount]['id'] = $company->getId();`должна быть `$retData[] = ['id' => ...]; иначе читабельность падает в разы и приходится искать что ты пытаешься мутировать в оригинальном массиве. а вообще ты свой сериализатор изобрел?)
метод generate и все что с ним идет как я уже говорил - в отдельную cli команду. в крайнем случае отдельный контроллер + сервис к нему, если нужно из веба вызывать, что я сомневаюсь.
sql запросы должны быть в репозиториях.
мапинг реквест параметров на сущность сделан через жопу. для этого ж можно взять формы симфони или же сделать свой парам конвертер.
валидация сделана через такую же жопу. у симфони есть свой валидатор, который работает более чем отлично.
чем обусловлен выбор карбона? api php не хватало?
я смотрю протащил еще в композер rest-bundle. он используется где-то?

тут в принципе той логики как кот наплакал и если б сделал нормально мапинги, сериализации и валидации тебе б не пришлось даже в сервисы что-то уводить

Ох, спасибо за разъяснения....