rPman

https://developers.google.com/fit/android в т.ч. прямое чтение сенсоров в реальном времени
ну и само устройство должно поддерживать

p.s. осторожно, носимые устройство дизайнятся как энергосберегающие, постоянное чтение данных сожрет батарею в считанные час или даже минуты.

Потрясающе, это же криптовалюта, абсолютно все что тебе нужно можно получить и посчитать самому

https://bitcointalk.org/index.php?topic=2262328.0

EarningsPerMonth = (UserHashMh * 1e6 / ((difficultyTH / BlockTimeSec)*1000*1e9))*((60/ BlockTimeSec)*BlockReward)*(60*24*30)*(EthPrice)

UserHashMh = Mining servers hashpower (in MH/s)
Difficulty in TH/s
BlockTime in seconds
BlockReward = number of ETH per block mined (5 currently)
EthPrice in fiat

60*24*30 - интервал времени в минутах (потому что в формуле есть еще 60/ BlockTimeSec ...)
difficulty берут из запущенной ноды (но ты же не запустил), можно брать с эксплореров (история, api для получения таких параметров майнера реже дают, например тут )
BlockTime in seconds - можно взять за 13.25 в среднем или так же считать из блокчейна по блокам и времени в них (посмотри график)
BlockReward так же рекомендую брать из блоков, особенно если тебя история интересует

На скрине что за площадка?

Курс обмена валют это эффимерная абстракция, его можно получить, либо на конкретный момент времени в прошлом (последняя сделка) и что главное для конкретной биржи и каждой они отличаются, часто заметно, либо нечто усредненное за какое то время, опять так же в прошлом.

Цена последней сделки (ticks) никаким боком не гарантирует что следующая сделка будет исполнена по этой же цене.

На биржах есть api, но к этой цене нужно добавлять комиссию (легко 0.5% + за ввод вывод) плюс комиссия за риск изменения этой цены пока клиент думает (дается окно в несколько секунд времени, курс замораживается, чтобы показать его пользователю)

На большинстве бирж есть стакан из которого можно в каждый момент времени вычислять две цены - покупки и продажи, если совершить сделку по маркету, но в зависимости от объема сделки, числа будут получаться разными. Разница между этими ценами зовется спред, и если совершать сделку по рынку (не выставлять ордер и ждать когда он исполнится а просить биржу исполнить обмен по той цене что есть здесь и сейчас) то получается этакая комиссия (которая легко может быть 0.5...1%)

И самое главное, чем менее ликвидный актив, тем сильнее на разных площадках для него может отличаться курс (чаще в невыгодную для клиента сторону), в случаях когда появляется выгодные комбинации то у трейдеров возникает возможность арбитража и эти курсы выравниваются.
--------

теперь отвечаю на твой не высказанный вопрос - ты должен брать курс на той площадке, где ты собираешься вести свой бизнес, ты магазин и принимаешь криптовалюту но желаешь сразу ее конвертировать в другую? вот на основе курса той биржи, где ты это будешь делать и смотри!

попробуй другую библиотеку python-telegram

Самая крутая opensource библиотека для работы с криптобиржами, одновременно под несколько языков (php, python, javascript,...), - это ccxt, почти весь требуемый функционал (кроме проверки работы ввода вывода и по мелочи) там реализован для большинства бирж (смотри опции exchange.has), ходить на coinmarketcap не придется.

Работа с телеграм как клиент (а не бот) - telethon для python (кажется он лучше поддерживается)

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

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

и напоминаю, все биржи в криптоэкономике - нерегулируемые, это значит никакой регулятор не будет следить за тем чтобы биржа выполняла свои обязательства перед своими клиентами (как только ты начинаешь получать доход, биржи начинают чудить, вплодь до самовольного закрытия позиций по худшим ценам и банить без объяснения причин), так же никто не накажет биржу за обман и мошенничество (например фиктивные сделки в публикуемой информации о рынке - список лимитных и история сделок, грубо говоря ты видишь что на рынке много покупателей, делаешь крупную покупку в надежде потом это продать а покупатели фьють и исчезли)

что значит нет?
https://api1.binance.com/api/v3/ticker/price

usdt_rub например или tusd_rub

не совсем api но задачу решить можно
сбербанк, sms мобильный банк (т.е. посылать команды и получать ответы только через мобильного оператора)

кажется единственный p2p api работающий в россии, так как формально между пользователями переводить деньги - это плохо плохо, а вам прямо api целый для этого подавай

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

https://www.whatsapp.com/business/api
https://developers.viber.com/docs/api/

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

все остальные способы будут работать, симулируя работу обычного клиента, например через инжект скриптов веб клиент или симуляцию нажатий кнопок (на android чуть ли не штатный функционал через adb или разработку плагина для людей с ограниченными возможностями)

ваша crm готова к нагрузке, которую будет генерировать веб сайт?

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

выгруженные данные это кеш оригинальных данных, в принципе можно совместить подход, работать с api но обеспечить механизм хранения (в т.ч. заранее загруженых) копии данных в базе веб сервера, дополнив api crm инструментами по оповещению об изменении и обновлению этих данных.

p.s. мне нравится варианты построения на основе master-slave репликация базы crm средствами sql базы данных, все изменения будут оперативно (с очень минимальным лагом) заливаться в slave-реплику базы, и вот уже с ней может спокойно работать веб сервер как со своей, на чтение

--get --data-urlencode page=1

Тебе нужен не api к трекеру, а точная и качественная база торрент с безглючной связью с базой например кинопоиска.

Я такого не видел, если найдешь отпишись тут.

Проблема в данных, торент файлы создаются людьми для людей а не для машин, есть торент трекеры где за качеством следят, но это местечковые трекеры (попробуй старенький vtracker, забанен в россии, мало пользователей, но за контентом следят до сих пор, в имени публикации обязательно добавляется жанр.), глобально неудобные и главное в них очень мало данных.

Торент - это больше не хранилище данных (беда технологии, так как нет механизмов управления того какие торенты у клиентов должны храниться а какие удаляться, например редкие и наоборот слишком популярные) а некий оперативный буфер для контента здесь и сейчас, очень хорошо справляется когда сразу куча людей начинают что то скачивать но плохо с хранением на долго, особенно чего то не популярного. Отсюда народ не видит смысла правильно оформлять контент, например с обязательной ссылкой на кинопоиск/imdb и машиночитаемое описание с тегами по жанрам, авторам и т.п. чтобы поиск работал, и главное этот процесс сложно монетизировать и поддерживать в долгую.

Идеологически верное решение - установить Litecoin кошелек (чтобы не занимал много места, кажется до 500мб, нужно использовать опцию -prune=макс_размер_блокчейна_в_мб).

с помощью ключа командной строки
-walletnotify=<cmd>
можно принимать алерты об изменениях на балансе

с помощью rpc команд (примеры смотри у bitcoin так как litecoin почти идентичный его форк) делать запрос о конкретике, например создании адреса для приема монет, балансе адреса, создании новой транзакции или о количестве подтверждений

p.s. настоятельно рекомендую не хранить все балансы на кошельке, размещаемом на веб сервисе, нужно делить на горячий кошелек (оперативный балас) и холодный (большая часть баланса, работа с которым только вручную или по особым условиям).

Причина - защита основного баланса при взломе веб-сервера.

Еще лучше - не размещать кошелек там же где и веб сервис, а разделять по серверам, между которыми будет ходить твой собственный протокол связи, и сервер с кошельком должен параллельно анализировать базу переводов основного и выискивать несоответствия (это не абсолютная защита но создаст очень большие сложности атакующему, плюс можно разместить ловушки, rpc запросы или значения параметров, при которых владельцу будет присылаться алерт о том что сервис атакован).

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

Когда то, там где это было не критично, бакэенд я делал в виде примитивной прослойки для базы данных и хранения sql запросов, т.е. клиент в запросе выдавал идентификатор запроса и список его параметров именованным массивом, а сервер возвращал табличку как есть, код на php чуть ли не десяток строчек плюс список sql запросов. Если запросов за раз бывает много, ввести возможность отправки их пакетом....

Немного сложнее с запросами на модификацию, сами запросы не сложные но нужно будет как то описывать ограничения, что можно к примеру удалять или править а что нет, в общем под задачу, но точно так же как и с запросом данных на чтение, бакэнд выступает исключительно простой прослойкой к вызовам методов sql драйвера (понятно что до вызовов по методам доходить не стоит, т.е. к примеру после вставки записей insert можно тут же вызвать lastInsertId и вернуть его в ответе, а так же проверить на ошибки и собрать подробности (запихнуть в лог и выдать клиенту)