Телеком api что это
Открытый API в телефонии: решения простых бизнес-задач
В последнее время мы наблюдаем масштабный тренд развития открытого API, когда сервисы позволяют создавать на своей основе решения задач, которые по тем или иным причинам не лежат в функциональности самих сервисов. Этот тренд начинают раскачивать IT-гиганты, вроде Microsoft, IBM или Cisco. Для таких компаний, делающих ставку на облачные платформы, подобный тренд — золотая жила: где-то же должны храниться приложения, интегрирующие разные сервисы с открытым API.
К числу сервисов, поддерживающих тренд открытого API, принадлежит и UIS — мы активно работаем над развитием нашей инфраструктуры API для телефонии и других интеграционных инструментов (прим.: кому интересно — можно подробно посмотреть хотя бы на нашу интерактивную обработку вызовов или изучить другие возможности интеграции виртуальной АТС UIS c CRM-системами).
О масштабах тренда открытого API говорит и то, что Gartner, в своем квадрате, начал уделять внимание API Management платформам. То есть можно смело утверждать о том, что мы с вами становимся свидетелями формирования нового рынка — рынка простеньких приложений, интегрирующих различные сервисы между собой или создающих на базе API существующих сервисов новые продукты. Но обязательно ли быть программистом, чтобы создавать такие приложения? Совсем нет. Вот об этом — о том, какие сервисы позволяют самостоятельно сделать приложение без глубоких навыков программирования — я и хотел бы поговорить.
IFTTT — простой как в использовании, так и в возможностях. Вы настраиваете событие и реакцию на него. Например, потерянный звонок — событие, создание задачи в Trello — реакция.
И все: несколько кликов — и потерянные звонки заносятся в ваш менеджер задач. В IFTTT представлено более 300 сервисов, с которыми возможна интеграция. Несмотря на то, что в их число UIS не входит, вы можете самостоятельно сделать связку с нашими уведомлениями, например, с помощью коннектора Maker.
По своим возможностям Zapier является более серьезным инструментом, чем IFTTT. В том числе, потому что позволяет выстраивать более сложные логические цепочки, чем просто схема «событие-реакция». Отличия касаются и доступных коннекторов (кстати, в Zapier доступны более 500 коннекторов). Например, в их число входит коннектор к MySQL.
Microsoft Flow был представлен публике только в этом году, но среди рассматриваемых в этой статье инструментов он является наиболее функциональным. Конструктор позволяет строить не только логику «событие-реакция», но и создавать различные ветки обработки событий.
Ввиду молодости сервиса, в Microsoft Flow коннекторов еще очень мало. А поскольку это детище Microsoft, инструмент сфокусирован на продуктах и экосистеме именно этой компании.
Конечно, построить межгалактический корабль такими инструментами не получится. Но некоторые приземленные задачи они решить вполне способны. Например:
обеспечить дополнительные каналы получения уведомлений (вроде всеми любимых мессенджеров);
автоматизировать создание лидов и контактов в CRM для входящих звонков;
собирать статистику по обращениям в третьих IT-системах;
автоматически перезванивать при пропущенных звонках;
превращать заявки с сайта в звонки;
получать ссылки на записи разговоров по телефону в Skype;
заносить заявки с сайта как задачи в менеджер задач.
Вообще, появление подобных сервисов-конструкторов иллюстрирует интересное будущее: если раньше программирование ассоциировалось с чем-то сложным и непонятным, то сейчас его доступность растет в геометрической прогрессии. Возможно, уже наши дети, достигнув пожилого возраста, будут не вязать внукам свитера, а писать какие-то приложения. И машины будут звонить хозяевам с напоминанием отвести их на техосмотр, холодильники будут напоминать купить продукты, а позвонить в «магазин на диване» можно будет по нажатию одной кнопки на пульте от телевизора.
Стать ИТ-компанией: какие тренды использует МТТ для развития бизнеса
Переход от традиционной модели к внедрению ИТ-решений.
Около десяти лет назад, когда телекоммуникационная индустрия росла стремительными темпами как в финансовом, так и в технологическом плане, оператор МТТ работал на двух рынках: дальней связи и транзита трафика, предоставляя операторам доступ к сетям. Отсюда название компании — «Межрегиональный ТранзитТелеком».
Последние несколько лет МТТ постепенно трансформировался с учетом меняющегося рынка телекома и ИТ, и сегодня окончательно перешел на новую бизнес-модель, став провайдером интеллектуальных решений для бизнеса. Пройдя этот путь и имея существенный опыт в предоставлении b2b-сервисов, в компании смогли выявить несколько трендов, которые помогают диверсифицировать бизнес и сделать его более успешным.
Суть тренда: продажа инструментов для работы с клиентами — виджетов обратной связи, чатов, коллтрекинга и других решений.
компаний автоматизировали продажи с помощью сервисов МТТ
МТТ запустил на базе виртуальной АТС платформу pozvonim.com, с помощью которой можно подключать виджеты к своим площадкам. Российские предприниматели более открыты ко всему новому и активнее используют технологии, которые позволяют получать дополнительных клиентов и прибыль. По данным МТТ, с 2016 года количество компаний, которые используют сервисы оптимизации бизнеса, выросло с 26% до 52%.
Мы хотим сделать нашу виртуальную АТС не похожей на то, что предлагают другие компании. Наш продукт ориентирован прежде всего на повышение эффективности взаимодействия компаний с клиентами. Новые функции, которые мы добавляем, — это оптимизация коммуникаций, аналитики и качества сервисов при продаже и обслуживании. Это уже не телекоммуникационное решение в чистом виде, оно находится на стыке с ИТ, CRM и BI.
Суть тренда: продажа телеком-возможностей на платформе МТТ для интеграции в приложения и сайты.
выросла клиентская база телеком-платформы МТТ с 2016 по 2017 год
МТТ разрабатывает готовые решения с различными телеком-функциями для разных типов бизнеса. Например, персонализация голосового меню для интернет-магазина. Или подмена реального номера мобильного телефона на виртуальный во время звонка клиента таксисту.
Продажа API в телекоме перестала быть костылем, с помощью которого бизнес «как бы» решает свои проблемы. Наоборот, сейчас телекоммуникационные API фактически создают фундамент для многих сервисов и мобильных приложений. Мы предложили новые кейсы использования виджетов, сделали удобные инструменты для выбора и подключения таких решений. Направление Telecom API растет быстро, и спрос превышает предложение. Клиенты просят от нас даже большего, чем может предложить рынок.
Суть тренда: один из наиболее ёмких и быстрорастущих технологических рынков пока остаётся неопределённым. Неизвестно, какие технологии будут разрешены в России, какие производители будут работать, и кто из крупных клиентов готов к инвестициям в этой области. Но уже сейчас понятно, что эти технологии станут драйверами рынка.
планирует заработать МТТ на рынке интернета вещей через четыре года
В течение года в МТТ проводили исследование рынка интернета вещей и пришли к выводу, что бизнес телеком-компании на нём должен отличаться от простой операторской модели. Построить сеть и продавать подключение за абонентскую плату неэффективно. Почти во всех случаях использования интернета вещей можно обойтись без развертывания глобальной сети, главное — выстроить платформу и логику оказания услуг.
Согласно стратегии компании, МТТ возьмет на себя роль владельца и разработчика IoT-платформы. Продажей и обслуживанием оборудования, разработкой приложений и облачных сервисов займутся партнеры.
Наши потенциальные клиенты в области интернета вещей — это государственные корпорации. Но, скорее всего, нам будет сложно играть на их рынках. Мы не готовы к тому циклу принятия решений, который существует в таких компаниях: как правило, он слишком длинный и не подходит для оперативных действий на оживленном рынке.
Но необходимость в интернете вещей есть не только и не столько у огромных корпораций, поэтому прежде всего мы обращаем внимание на потребности среднего и малого бизнеса. Спрос есть в индустриях ритейла, сельскохозяйственных услуг, транспорта и логистики.
Реализация Frameworx в телекоммуникационном API
Скорость развития рынка телекоммуникаций вынуждает его участников непрерывно совершенствовать свои бизнес-процессы, снижая себестоимость и максимально сокращая время разработки и вывода новых услуг на рынок. Большой проблемой при этом становится построение правильных бизнес-моделей внутри организации. В процессе реализации услуги YouMagic.Pro мы столкнулись с тем, что каждый продуктолог, который начинал заниматься этим проектом, видел его развитие по-своему. Менялись интерфейсы, формы, мы переписывали код, и все это приводило к ошибкам в работе сервиса. В какой-то момент заявленные требования уже перестали быть совместимыми с изначальной архитектурой и мы решили посмотреть, как реализованы бизнес-процессы в других телеком-компаниях. В результате анализа мы пришли к решению внедрить референтные модели SID Frameworx от ТМ Forum. В этой статье мы расскажем, что же такое референтные модели и с чего нужно начинать разработку телеком-сервисов, которые в дальнейшем будут способны адаптироваться под различные изменения бизнес-требований.
Референтные модели
Итак, что же такое референтные модели и откуда они взялись.
Для начала рассмотрим понятия бизнес-инжиниринга и инженерного подхода. С помощью технологии бизнес-инжиниринга можно создавать, изменять и реорганизовывать предприятия, а также обеспечивать согласованность различных их компонентов: стратегии, структуры, бизнес-процессы, информационные системы и т. д. Бизнес-инжиниринг, в свою очередь, основан на инженерном подходе, важной особенностью которого является использование формализованных знаний, приспособленных для повторного использования.
Формализованные знания — это знания, которые можно описать, задокументировать и рассказать о них другим людям. Их представляют в графической форме, в виде рисунков, спецификаций, учебников, процедур. Они могут быть словами, номерами и объектами. С точки зрения практики повторно используемые ресурсы и формализованные знания можно разделить на следующие категории:
Во всем разнообразии повторно используемых ресурсов нас заинтересовали референтные модели разработки, внедрения и эксплуатации программного обеспечения для телекома. Они представляют собой эталонные схемы, процедуры и методы организации бизнеса, разработанные на основе реального опыта внедрения в различных компаниях по всему миру. В рамках этой статьи мы остановимся на концепции референтных моделей Frameworx для телекоммуникационных компаний.
Преимущества реализации существующих моделей над проектированием с нуля
Телекоммуникационные и информационные технологии, а также ассортимент предлагаемых компаниями связи услуг развиваются и изменяются чрезвычайно динамично. Сейчас бизнес не может тратить на разработку услуги 1–2 года, как было в связи ранее. В настоящее время срок выхода сервиса на рынок измеряется месяцами. Вместе с ними в постоянном развитии находятся компоненты управляющих информационных систем, а также сами бизнес-процессы. При этом компании довольно часто не располагают временем для проведения полномасштабного проектирования новых процессов. Что уж говорить о разработке, тестировании и внедрении управляющих модулей, которые будут реализовывать в системах новые услуги.
Ещё одной сложностью в управлении бизнес-процессами в телекоммуникационных компаниях является то, что они автоматизируют взаимодействие с клиентами, давая им возможность самостоятельно в реальном времени управлять предоставляемыми услугами. Чаще всего это происходит через веб-интерфейс.
Большинство программистов, или просто технарей, на вопрос про бизнес-процессы в компании ответят: «Это описание того, как заявка от сотрудника поддержки передается в CRM техническому специалисту». Или приведут другой пример из жизни любой компании. Мы посмотрели на это с другой стороны. Подключение клиента и его работа в личном кабинете — это тоже бизнес-процесс. Также существует большое количество скрытых от пользователя бизнес-процессов. Например, разблокировка при пополнении баланса; активация скидок при заказе определенного набора или объема услуг. Все эти бизнес-процессы в подавляющем большинстве случаев автоматизированы в услугах. Когда бизнес-процесс автоматический, то субъекты (люди) практически отсутствуют, и код управляет объектами бизнес-процесса. И поскольку субъекты — это код, то он не может принять человекоподобные решения в условиях недостаточности информации. В таком варианте на первое место выходит построение универсальных и эффективных моделей данных для манипуляции ими автоматическим кодом.
В процессе проектирования ядра продукта «МТТ Бизнес» мы изучили существующий опыт и нашли решение: использовать информационные фреймворки. Они описывают типовые структуры построения моделей, данных для отраслей или предметных областей. Начиная от общего описания основных объектов (для нас, например, это клиент, услуга, тариф и т. д.) и вплоть до конкретных диаграмм компонентов, уже описанных в нотации UML. В них уже заложены best-practices опыта специалистов, которые решали аналогичные проблемы ранее.
Почему мы выбрали ТМ Forum и Frameworx
Tele Management Forum (TM Forum) — это некоммерческая ассоциация, которая объединяет предприятия электросвязи и их поставщиков с целью написания стандартов, рекомендаций и моделей для информационных технологий в телекоммуникационной отрасли. Ассоциация основана в 1988 году по инициативе компаний British Telecom и AT&T и сначала называлась OSI/Network Management Forum. К началу 1989 года была одобрена первая спецификация протокола OSI/NM Forum, а уже в 1990 году в организацию входило 85 компаний из 13 стран. В дальнейшем TM Forum объединила практически все мировые телекоммуникационные компании.
Основными направлениями исследований и разработок TM Forum стали:
Концепциями TM Forum пользуются во всем мире лидеры рынка информационных и телекоммуникационных услуг.
Frameworx
Frameworx — это развитие концепции NGOSS. Как уже было сказано, основная задача этой концепции состоит в определении стандартов для бизнес-процессов операторов связи, а также в унификации форматов представления используемых в системах управления данных и интерфейсов. Особенности концепции Frameworx стали несколько факторов.
1. Разделение бизнес-процессов и применяемых технических компонентов.
Любой бизнес-процесс должен управляться как часть централизованной инфраструктуры. Для этого используются механизмы, которые обеспечивают последовательность выполнения действий. Они также отвечают за осуществление контроля хода бизнес-процесса от одного приложения до другого.
2. Распределенная система с нежесткими связями между ее элементами.
Frameworx подразумевает под собой создание «распределенных систем» с нежесткими связями между их элементами. Это означает, что вместо единого монолитного приложения для управления всеми операциями телекоммуникационной компании предлагается использовать набор интегрированных и взаимодействующих друг с другом приложений.
3. Общая информационная модель.
Приложения, работающие в концепции Frameworx, должны уметь обмениваться друг с другом различного рода данными. При этом каждое приложение должно понимать, как любое другое приложение интерпретирует любой блок переданных данных. Подобная модель работы называется общей информационной моделью.
Основу концепции образуют карты и модели бизнес-процессов. Frameworx включает в себя следующие структуры:
SID Framework
Информационная модель (information framework) является составной частью Frameworx и определяет подход к описанию и использованию данных, задействованных в бизнес-процессах компании связи.
Информационная структура (SID) представляет собой базовую модель и общий словарь всей информации, необходимой для осуществления бизнес-процессов. Использование SID снижает сложность обслуживания, системной интеграции, разработки и проектирования.
С точки зрения практики SID Framework можно представить в виде схемы.
Как и где мы применили SID
Продукт «МТТ Бизнес» имеет двухуровневую архитектуру:
При принятии такого решения мы также понимали, что помимо одного портала продукта «МТТ Бизнес» к тому же API могут быть подключены другие порталы, реализующие аналогичные услуги и бизнес-правила. Наши ожидания оправдались, и через год после запуска в продакшен продукта «МТТ Бизнес» мы подключили к API двух партнеров с аналогичными услугами без каких-либо существенных доработок.
Для реализации бизнес-логики в API мы реализовали несколько доменов SID Framework: Product, Customer, Service, Resource. Реализация услуги «МТТ Бизнес» на этапе разработки не потребовала реализации всех бизнес-сущностей (ABE) из этих доменов. Это связано с тем, что, например, процесс сопровождения услуги реализован в других системах и такие бизнес-сущности, как Customer Problem, Customer SLA, Service Trouble и т. д., покрываются этими системами. На схеме ниже отражены бизнес-сущности, реализованные в «МТТ Бизнес».
«МТТ Бизнес» имеет приватное API, которое позволяет партнерам МТТ реализовать аналогичные телеком-услуги с его помощью. Если при этом ориентироваться только на интерфейсы API, то можно заметить, что они не в полной мере отражают SID Framework. Он реализован внутри и составляет скрытое от пользователя API ядро. Такой выбор был намеренным — в самом API отражены конечные бизнес-процессы, а не абстракции.
SID также содержит рекомендации по реализации взаимодействия между бизнес-сущностями разных доменов. В нашем случае основное взаимодействие локализовано между продуктами, услугами и ресурсами. Лучше всего это отражает соответствующая диаграмма SID.
Для наглядного представления того, как использованы эти бизнес-сущности и домены в «МТТ Бизнес», на диаграмме ниже отражены маркетинговые наименования услуги «Виртуальная АТС», которая является одной из ключевых в «МТТ Бизнес».
Что дальше?
Любой выбор предполагает последующую оценку эффектов, к которым он приводит. Формализовано или нет. Конечно, когда мы выбирали этот подход, мы не были уверены, эффективен ли он будет в дальнейшем развитии кода, систем, услуг и продукта. И предполагали, что потребуется формальный аудит и оценка, пусть, возможно, и внутренняя, для себя. Однако сама собой прошла «проверка жизнью». В процессе многочисленных доработок, внедрений новых услуг, реализации маркетинговых акций и пр. доработки кода во многих случаях были минимальными, что позволило реализовать больше идей бизнеса, чем это было возможно в услугах с проектированием архитектуры без оглядки на референтные информационные модели. Сейчас в планах реализовать этот подход к управлению данными на уровне всего предприятия для реализации стратегической цели по интеграции и созданию любого сервиса на платформе МТТ за 2 недели.
Референтные модели и технологии бизнес-инжиниринга
Кудрявцев Д.В. Технологии бизнес-инжиниринга: учеб. пособие / Д.В. Кудрявцев, М.Ю. Арзуманян, Л.Ю. Григорьев. — СПб.: Изд-во Политехн. ун-та, 2014. — 427с.
Телеком api что это
API (Application Programming Interface – программный интерфейс приложений) – технология взаимодействия программных систем (обмена данными). API, предоставляемые программными продуктами компании MCN Telecom, дают возможность различным сторонним бизнес-приложениям обмениваться с ними данными и управлять их функциями. Интеграция бизнес-приложений с виртуальной АТС, телефонией и другими продуктами компании MCN Telecom с применением API позволяет автоматизировать бизнес-процессы, использовать единый интерфейс, эффективно организовать работу сотрудников и подразделений компании.
API представляет собой набор правил обмена данными между программными системами. В таком взаимодействии одна из систем предоставляет API, и другие системы могут его использовать, для чего в их код встраиваются операции обращения к функциям API. Как правило, взаимодействие происходит путём обмена сообщениями. Передаваемые данные могут содержать, в частности, запросы одной из систем на выполнение операций в другой; в ответ могут быть переданы результаты обработки запроса.
Технология WebHooks – разновидность API, в которой передача сообщений инициируется системой, предоставляющей API, т. е. о событиях в ней внешние системы получают уведомления моментально.
Другим вариантом является передача данных, инициируемая из внешней).
Действия, запущенные через API, приложениями MCN Telecom выполняются и тарифицируются обычным образом – точно так же, как и инициированные другими способами. Например, звонки, выполненные по API, для телефонной сети неотличимы от звонков с обычного телефона, и тарифицируются по той же цене.
Возможности API MCN Telecom
Возможности API MCN Telecom, в частности, включают:
Управление функциями ВАТС и телефонии через API (и в т. ч. с использованием WebHooks) может включать такие действия, как:
Интеграция ВАТС с CRM позволяет:
Как воспользоваться API MCN Telecom
API MCN Telecom постоянно расширяется, дополняется новыми методами, наиболее часто запрашиваемыми нашими клиентами. При выпуске новых версий API прежние остаются доступными для использования.
Чтобы воспользоваться API, нужно произвести настройки в Личном кабинете в разделе API, а также во внешней системе (использующей API MCN Telecom).
Для авторизации при обращении по API используется секретный ключ (токен), который должен быть предварительно сгенерирован и далее записан в использующей системе, где необходимо.
Документация API с подробным описанием методов доступна в Личном кабинете.
Интеграция с CRM-системами
Для интеграции с наиболее популярными CRM-системами – amoCRM, Битрикс24 и др. – можно воспользоваться уже разработанными готовыми модулями. Подключение телефонии и виртуальной АТС MCN Telecom к Вашей системе займет порядка 10 минут. Различные CRM-системы направлены на единый спектр задач бизнеса, а потому их функциональность сходна, и принципы интеграции одинаковы. Это совершение звонков из CRM-системы в один клик, поднятие карточки клиента при входящем звонке, автоматическое направление звонка на персонального менеджера, возможность получить полную историю звонков и запись разговоров, построение отчётов и пр..
Интеграция телеком-платформы MCN Telecom с собственными приложениями абонентов и популярными сервисами, в т. ч. CRM-системами, возможна несколькими вариантами:
Выбор оптимального варианта интеграции (из доступных) зависит от конкретных требований к взаимодействию систем.
Применение коннектора интеграций позволяет настраивать взаимодействие телеком-платформы MCN Telecom со множеством систем простым единообразным способом и без участия программистов.
Механизмом интеграции являются API/WebHooks MCN Telecom. Для подключения систем через коннектор интеграций нужно выполнить стандартные настроечные операции на сайте коннектора и в подключаемых системах, в т. ч. в ЛК клиента MCN Telecom.
API простым языком: что это и зачем нужен
API (Application Programming Interface или интерфейс программирования приложений) — это совокупность инструментов и функций в виде интерфейса для создания новых приложений, благодаря которому одна программа будет взаимодействовать с другой. Это позволяет разработчикам расширять функциональность своего продукта и связывать его с другими.
Большинство крупных компаний разрабатывают API для клиентов или для внутреннего использования. Обычные пользователи тоже применяют разные API. РБК Тренды объясняют, как это работает.
Когда пользователь посещает любую страницу в интернете, он взаимодействует с API удаленного сервера. Это составляющая сервера, которая получает запросы и отправляет ответы. Кроме того, благодаря API человек может совершать различные действия, не покидая сайт. Именно для этого большинство современных сайтов используют по крайней мере несколько сторонних API, которые предлагают сторонние разработчики. Также компании разрабатывают собственные API и продают их как готовый продукт. К примеру, Weather Underground, которая принадлежит IBM, продает доступ к своему API для получения метеорологических данных. Эту информацию используют погодные приложения и сервисы.
ProgrammableWeb, веб-сайт, посвященный экономике API, в настоящее время отслеживает более 24 тыс. различных программных интерфейсов. Существуют сотни API для финансовых систем, обмена сообщениями в социальных сетях, платежей, электронной коммерции, криптовалют и прочих сфер. Наиболее быстрорастущий сегмент API относится к обмену и анализу данных в различных приложениях.
Как работает API
Интерфейс представляет собой промежуточный слой между двумя приложениями. Он позволяет двум программам обмениваться информацией и выполнять функции, не раскрывая своего внутреннего API. Скрытие части функций называется инкапсуляцией.
Есть три метода взаимодействия с API:
Разработчик имеет полную свободу в выстраивании функций API. Например, отдельный набор функций может определять возможность регистрироваться и авторизоваться в программе.
API бывают публичные и частные. Первые предназначены для совместного использования с внешним миром, например, API YouTube. Сторонние разработчики могут создавать приложения, чтобы воспользоваться возможностями этих интерфейсов. Вторые — это внутренние приложения, разработанные для определенной аудитории или пользовательской базы. Они часто используются на предприятиях и внутри компаний. Для работы с таким API нужно получить доступ.
Для чего используют API
Разработчикам программный интерфейс позволяет:
До появления Windows и других графических операционных систем программистам для создания окон на экране компьютера приходилось писать тысячи строк кода. Когда же Microsoft предоставила разработчикам API Windows, на создание окон стало уходить всего несколько минут работы.
Бизнесу API нужны, чтобы:
В 1990-е годы организация, которая хотела запустить систему управления взаимоотношениями с клиентами (CRM), была вынуждена вкладывать огромные средства в программное обеспечение, оборудование и специалистов. Теперь компании используют облачные службы вроде Salesforce. Доступ на уровне API к функциям Salesforce позволяет бизнесу включить ключевые элементы функциональности CRM-системы — например, возможность просматривать историю клиента.
Правительствам API позволяют:
Уже в 40 городах США используется бесплатный API Open311, который позволяет отслеживать проблемы на основе местоположения пользователя. Человеку достаточно лишь отправить в городскую систему фото с выбоиной на дороге и указанием геолокации.
Примеры API в нашей жизни
Google Календарь. Приложение-календарь на Android разработает на API, позволяющем подключить свой календарь напрямую к сторонним приложениям. Пользователи могут использовать несколько разных программ с встроенными и обновляемыми календарями, где будут все важные события, встречи и т.д. Компании могут встраивать API календаря на свои сайты, чтобы, к примеру, записывать своих клиентов на прием. Встраивание в форму записи Google Календаря позволяет клиентам автоматически создавать событие и вносить детали о предстоящей встрече. Благодаря API сервер сайта напрямую обращается к серверу Google с запросом на создание события, получает ответ Google, обрабатывает его и передает соответствующую информацию в браузер, которая поступает клиенту в виде сообщения с подтверждением.
Заказ авиабилетов. Многие пользуются агрегаторами билетов, такими как Aviasales и SkyScanner. Такие сервисы собирают информацию о стоимости авиабилетов в разных авиакомпаниях и отображают ее в едином окне. Это позволяет реализовать API, встроенный в сайты авиакомпаний, который помогает в реальном времени обновлять информацию о направлениях и стоимости.
Навигация на сайтах и в приложениях. Крупные компании, в том числе Apple, Google, «Яндекс» и другие, разработали API, позволяющие подключить собственный картографический сервис к другим площадкам. Так, в «Яндекс.Карты» встроены сервисы «Транспорт» и «Пробки». Многие приложения на Android, например, по доставке еды или для спорта, используют встроенный в ОС API, чтобы подключить карты Google к своему сервису. На iOS аналогичная ситуация с Apple Maps.
Кнопки авторизации. На многих сайтах есть кнопки, позволяющие зарегистрироваться через уже существующие аккаунты на популярных площадках и в соцсетях. Это возможно благодаря API, которые есть у Google, Facebook, Apple, Twitter, «ВКонтакте» и других компаний.