Как получить доступ к API СДЭК: ключи, токен и настройка интеграции

Блог / Инструкции и обучающие материалы / Как получить доступ к API СДЭК: ключи, токен и настройка интеграции

Инструкции и обучающие материалы Сравнение и обзоры услуг Опыт и советы по логистике Про СДЭК и нашу команду Новости компании

API СДЭК позволяет связать интернет-магазин, систему управления клиентами, учётную программу или собственный сервис с инфраструктурой службы доставки. Через такое подключение можно автоматически рассчитывать стоимость перевозки, получать список пунктов выдачи, создавать отправления, формировать накладные, запрашивать статусы заказов и передавать сведения о доставке покупателю.

Но прежде чем сайт начнёт обмениваться данными со СДЭК, необходимо получить доступ к API, создать ключи и настроить авторизацию. На этом этапе чаще всего и возникают вопросы:

Как создать токен
Где взять API СДЭК
Как получить доступ к CDEK API
Где найти ключи в личном кабинете
Почему сервер возвращает ошибку 401
Нужен ли договор со СДЭК для интеграции
Чем тестовый сервер отличается от рабочего
Что указывать в полях client_id и client_secret

Разберём весь процесс последовательно – от подготовки договорного аккаунта до первого успешного запроса.

Кратко – как получить ключи API СДЭК

Чтобы получить доступ к API СДЭК, необходимо:

Заключить договор со СДЭК и получить доступ к договорному личному кабинету.
Войти в личный кабинет под аккаунтом, к которому привязан договор.
Открыть раздел «Интеграция».
Нажать кнопку «Создать ключ».
Сохранить идентификатор аккаунта и секретный пароль.
Передать эти данные серверной части сайта или разработчику.
Отправить запрос на получение временного токена.
Использовать полученный токен в последующих обращениях к API.

Ключ можно создать в личном кабинете в разделе «Интеграция». После создания в этом разделе появляются идентификатор аккаунта и пароль.

Важно! Ключи API СДЭК и токен – не одно и то же. Идентификатор и секретный пароль используются для получения токена, а уже токен передаётся при запросах к методам API.

Что такое API СДЭК

API – это программный интерфейс, через который две информационные системы обмениваются данными без ручного переноса информации.

В обычном сценарии менеджер получает заказ, открывает личный кабинет СДЭК, копирует имя покупателя, телефон, адрес, вес и габариты товара, выбирает тариф и создаёт накладную. После этого он отдельно проверяет статус доставки и сообщает номер отправления клиенту.

При интеграции через API значительную часть этих действий выполняет система:

Покупатель оформляет заказ
Сайт рассчитывает стоимость доставки
Клиент выбирает пункт выдачи или доставку до двери
Данные заказа передаются в СДЭК
Создаётся отправление
Система получает номер накладной
Статусы возвращаются на сайт или в систему управления клиентами
Покупатель получает уведомления.

Что можно делать через API СДЭК?

Набор доступных операций зависит от используемых методов, условий договора и архитектуры интеграции. Через CDEK API можно решать следующие задачи.

Рассчитывать стоимость и срок доставки

Интернет-магазин передаёт города отправления и получения, вес, габариты и другие параметры. В ответ система получает доступные тарифы, ориентировочную стоимость и срок перевозки.

Это позволяет показывать условия доставки непосредственно в корзине, а не рассчитывать их вручную после оформления заказа.

Получать список городов

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

Показывать пункты выдачи

Сайт может получать сведения о пунктах выдачи заказов:

Адрес
Телефон
Код пункта
Координаты
График работы
Доступные услуги
Ограничения по весу или габаритам
Возможность приёма и выдачи отправлений.

Покупатель выбирает удобный пункт во время оформления заказа, а его код передаётся в создаваемое отправление.

Создавать заказы и накладные

После оформления покупки система может автоматически передать данные получателя, отправителя, упаковки и тарифа в СДЭК.

В результате создаётся отправление, которому присваивается идентификатор и номер накладной.

Получать статусы

Интеграция может запрашивать историю изменения статусов и передавать её:

В административную панель интернет-магазина
В систему управления клиентами
В личный кабинет покупателя
В систему уведомлений
В службу поддержки.

Формировать печатные документы

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

Автоматизировать возвраты и отмены

При правильно построенной интеграции можно учитывать отменённые заказы, возвратные отправления и другие нестандартные сценарии.

Кому нужен доступ к API СДЭК

API обычно используют компании, которым недостаточно ручного оформления отправлений через личный кабинет.

Интеграция полезна:

Интернет-магазинам
Юридическим лицам
Сервисам управления заказами
Разработчикам торговых площадок
Индивидуальным предпринимателям
Самозанятым с регулярными отправками
Компаниям с собственной системой учёта
Бизнесу с большим количеством накладных
Продавцам, работающим через несколько каналов
Компаниям, которым нужны нестандартные правила доставки.

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

Собственное подключение по API целесообразно, если нужно:

Объединить несколько складов
Реализовать нестандартный расчёт
Передавать заказы из разных систем
Автоматизировать массовое создание отправлений
Связать доставку с системой управления клиентами
Синхронизировать статусы с внутренней программой
Использовать собственный интерфейс выбора пункта выдачи
Управлять дополнительными услугами по внутренним правилам.

Что необходимо для получения доступа

До начала подключения следует подготовить договорный аккаунт и определить, какая система будет работать с API.

Договор со СДЭК

Для полноценной интеграции доставки бизнесу нужен договор со СДЭК. После подключения компания получает договорный аккаунт и доступ к рабочим инструментам. Договор может оформляться на:

Самозанятого
Юридическое лицо
Индивидуального предпринимателя
Интернет-магазин, работающий через соответствующий правовой статус.

Сам по себе обычный пользовательский аккаунт физического лица не следует считать полноценной заменой договорному доступу для коммерческой интеграции.

Доступ к личному кабинету

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

После входа проверьте:

Отображается ли договор
Доступны ли договорные тарифы
Можно ли создавать отправления
Присутствует ли раздел интеграций
Правильно ли указана организация
Видны ли документы и история операций.

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

Серверная часть сайта

Запросы, в которых используется секретный пароль, должны выполняться на сервере.

Для интеграции потребуется:

Серверное приложение
Система управления сайтом с подходящим модулем
Серверный обработчик на PHP, Python, JavaScript, Java, C# или другом языке
Система управления клиентами или учёта, поддерживающая подключение СДЭК
Интеграционная платформа, если она умеет безопасно хранить секретные данные.

Нельзя размещать client_secret в открытом коде страницы. Если секретный пароль попадёт в JavaScript, установленный в браузере, его сможет увидеть посетитель сайта.

Где взять API СДЭК

Ключи создаются в договорном личном кабинете.

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

Шаг 1. Войдите в личный кабинет

Используйте договорный аккаунт компании. После входа убедитесь, что открыли кабинет бизнеса, а не обычный профиль физического лица.

Шаг 2. Найдите раздел «Интеграция»

Откройте меню настроек или раздел управления интеграциями. Искомый пункт может называться:

«Интеграция»
«Интеграции»
«API»
«Ключи интеграции»
«Настройки интеграции».

Сейчас в актуальной документации СДЭК используется название «Интеграция».

Шаг 3. Нажмите «Создать ключ»

После создания система должна показать пару данных для авторизации. В разных версиях интерфейса и документации могут использоваться обозначения:

Account
Secure password
Идентификатор аккаунта
Пароль
Client ID
Client Secret.

Это не четыре разных ключа. Речь идёт о двух значениях, которые используются для получения токена.

Шаг 4. Сохраните данные

Передайте ключи только ответственному разработчику или администратору.

Секретный пароль нельзя:

Вставлять в код страницы
Размещать на снимках экрана
Отправлять в открытый общий чат
Публиковать в техническом задании с общим доступом
Добавлять в общедоступное хранилище исходного кода
Передавать сторонним исполнителям без необходимости.

Если ключ оказался в открытом доступе, его следует заменить.

Что такое client_id и client_secret

Для получения токена используются два основных параметра.

client_id

client_id – идентификатор клиента.

В документации или личном кабинете он также может называться:

Account
Client ID
Логин интеграции
Идентификатор аккаунта.

Он сообщает серверу СДЭК, от имени какого договорного аккаунта выполняется авторизация.

client_secret

client_secret – секретный пароль клиента.

В интерфейсе он может называться:

Пароль
Client Secret
Secure password
Секретный ключ.

Этот параметр подтверждает право системы получать токены для указанного аккаунта.

Не следует использовать вместо этих двух значений:

Номер накладной
Номер договора
ИНН организации
Телефон аккаунта
Адрес электронной почты
Пароль сотрудника от личного кабинета.

API-учётные данные создаются отдельно от обычного входа пользователя.

Почему API СДЭК использует токен

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

Общая схема выглядит так:

Ваш сервер отправляет client_id и client_secret на адрес авторизации.
СДЭК проверяет данные.
Сервер получает access_token.
Токен передаётся в заголовке последующих запросов.
После истечения срока действия система получает новый токен.

СДЭК использует авторизацию OAuth 2.0 с типом client_credentials. В ответе сервер возвращает access_token, тип токена и срок его действия (при разработке следует ориентироваться на фактическое значение поля expires_in в ответе).

Рабочая и тестовая среда СДЭК

Перед запуском интеграции нужно различать две среды.

Тестовая среда

Тестовый сервер предназначен для разработки и проверки запросов.

Базовый адрес: https://api.edu.cdek.ru/v2

Он позволяет проверять формат запросов и логику интеграции без работы с реальными отправлениями.

Рабочая среда

Рабочий сервер используется после завершения тестирования.

Базовый адрес: https://api.cdek.ru/v2

Запросы в этой среде относятся к настоящему договорному аккаунту и могут создавать реальные операции.

Официальная документация разделяет рабочие и тестовые адреса API. Для получения рабочего токена используется адрес api.cdek.ru, а для тестового – api.edu.cdek.ru.

Почему нельзя смешивать среды

Распространённая ошибка – запросить токен на одном сервере, а затем отправить его на другой.

Неправильный сценарий:

Токен получен на тестовом сервере.
Запрос отправлен на рабочий сервер.
API отвечает ошибкой авторизации.

Токен, адрес запроса и учётные данные должны относиться к одной среде.

Перед запуском проверьте:

Какой адрес авторизации используется
Для какой среды выданы данные
На какой сервер отправляется основной запрос
Не остался ли тестовый адрес в настройках
Не подставлены ли рабочие ключи в тестовую конфигурацию или наоборот.

Как получить токен API СДЭК

Для авторизации отправляется POST-запрос.

Рабочий адрес: https://api.cdek.ru/v2/oauth/token

Тестовый адрес: https://api.edu.cdek.ru/v2/oauth/token

В тело запроса передаются:

grant_type со значением client_credentials
client_id с идентификатором аккаунта
client_secret с секретным паролем.

Тип содержимого запроса: application/x-www-form-urlencoded

Пример запроса через cURL

curl --request POST \

--url "https://api.cdek.ru/v2/oauth/token" \

--header "Content-Type: application/x-www-form-urlencoded" \

--data-urlencode "grant_type=client_credentials" \

--data-urlencode "client_id=YOUR_CLIENT_ID" \

--data-urlencode "client_secret=YOUR_CLIENT_SECRET"

Вместо YOUR_CLIENT_ID и YOUR_CLIENT_SECRET необходимо подставить данные из личного кабинета.

Не публикуйте заполненный пример с настоящим секретным паролем в открытом доступе.

Пример ответа

При успешной авторизации сервер возвращает данные примерно следующего вида:

{

"access_token": "полученный_токен",

"token_type": "bearer",

"expires_in": 3599,

"scope": "order:all",

"jti": "идентификатор_токена"

}

Для выполнения следующих запросов нужен параметр access_token. Поле expires_in показывает, сколько секунд токен остаётся действительным.

Как использовать токен

Токен передаётся в заголовке Authorization.

Формат заголовка: Authorization: Bearer ACCESS_TOKEN

Между словом Bearer и токеном должен быть пробел.

Пример:

curl --request GET \

--url "https://api.cdek.ru/v2/location/cities?country_codes=RU&size=1" \

--header "Authorization: Bearer ACCESS_TOKEN"

Метод получения городов предусмотрен официальным API. Для него доступны параметры фильтрации, включая код страны и размер выборки.

Если сервер возвращает корректный ответ со сведениями о городе, авторизация работает.

Как правильно хранить и обновлять токен

Не нужно запрашивать новый токен перед каждым обращением к API.

Правильная логика:

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

Токен можно хранить:

В серверном кеше
В кеше приложения
В защищённой базе данных
В специализированном хранилище секретов.

Не следует хранить токен:

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

Почему нельзя получать токен через браузер

Иногда разработчик пытается отправлять запрос на авторизацию непосредственно из JavaScript на странице оформления заказа. Так делать не следует.

Для получения токена нужен client_secret. Если вставить его в клиентский код, посетитель сможет открыть инструменты разработчика и увидеть секретный пароль.

Правильная архитектура:

Браузер обращается к серверу интернет-магазина.
Сервер магазина обращается к API СДЭК.
Секретные данные остаются на сервере.
Браузер получает только необходимый результат – например, стоимость доставки или список ПВЗ.

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

Как проверить подключение

Не стоит начинать проверку с создания реального заказа.

Удобнее двигаться от простых методов к сложным.

Проверка 1. Получение токена

Убедитесь, что запрос авторизации возвращает:

access_token
token_type
expires_in

Если токена нет, переходить к следующим методам рано.

Проверка 2. Получение справочника

Запросите один город или небольшой список пунктов выдачи.

Это позволяет проверить:

Кодировку
Адрес сервера
Формат токена
Обработку ответа
Заголовок Authorization
Преобразование JSON.

Проверка 3. Расчёт тарифа

Передайте тестовый маршрут, вес и габариты.

Проверьте:

Срок
Валюту
Стоимость
Доступные тарифы
Сообщения валидации.

Проверка 4. Создание тестового отправления

Создайте заказ в тестовой среде и сохраните все идентификаторы, которые вернул сервер.

Проверка 5. Получение данных заказа

Запросите созданное отправление и сравните переданные данные с ответом.

Проверка 6. Отмена и повторный запрос

Проверьте, как система обрабатывает отмену, повторную отправку и сетевую ошибку.

Проверка 7. Рабочий запуск

После переноса на рабочий сервер оформите ограниченное количество контрольных отправлений.

На этом этапе проверьте:

Вес
Адрес
Тариф
Телефон
Габариты
Плательщика
Возврат статусов
Код пункта выдачи
Наложенный платёж
Печатные документы
Дополнительные услуги
Объявленную стоимость.

Что должно происходить после получения доступа

Получение ключей – только начало интеграции. Далее необходимо определить бизнес-процесс.

Расчёт доставки

Система должна понимать:

Откуда отправляется заказ
Куда он доставляется
Какой у него вес
Какие у него размеры
Кто оплачивает доставку
Доступна ли выдача в ПВЗ
Нужна ли доставка до двери
Какие тарифы разрешено показывать.

Создание отправления

Перед созданием накладной нужно проверить:

Город
Адрес
Код ПВЗ
Телефон
Габариты
Состав заказа
Имя получателя
Вес каждой упаковки
Количество упаковок
Объявленную стоимость
Сумму к оплате при наложенном платеже.

Получение статусов

Необходимо заранее решить:

Где хранить историю
Что делать при задержке
Как обрабатывать возврат
Когда отправлять уведомление
Какие статусы показывать клиенту
Как часто запрашивать обновления
Кто получает сообщение об ошибке.

Печатные формы

Нужно определить:

Кто отвечает за печать
Где печатается этикетка
Как документ привязывается к заказу
Что происходит при повторной печати
Как обрабатываются несколько упаковок.

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

Частые ошибки при получении доступа

Ошибка 400 Bad Request

Означает, что сервер не смог обработать параметры запроса.

Проверьте:

Есть ли client_id
Есть ли client_secret
Передан ли grant_type
Используется ли POST
Нет ли лишних кавычек и пробелов
Указано ли значение client_credentials
Установлен ли подходящий Content-Type
Правильно ли сформировано тело запроса.

Для токена параметры должны передаваться как данные формы, а не как произвольный JSON, если документация конкретного метода не указывает иное.

Ошибка 401 Unauthorized

Означает, что авторизация не прошла.

Возможные причины:

Токен истёк
Перепутаны поля
Неверный client_id
Неверный client_secret
Ключ ещё не активен
Выбрана неправильная среда
Секретный пароль был заменён
В значение попал лишний пробел
Вставлен пароль от личного кабинета
Использован номер договора вместо client_id
Заголовок Authorization сформирован неправильно.

Проверьте сначала получение токена отдельным запросом. Если токен не выдаётся даже в Postman или cURL, проблема находится не в коде сайта, а в учётных данных, среде или формате авторизации.

Ошибка 403 Forbidden

Обычно означает, что сервер распознал запрос, но не разрешает конкретную операцию.

Возможные причины:

Метод недоступен для аккаунта
У пользователя нет необходимых прав
Запрос относится к чужому отправлению
Операция запрещена для текущего состояния заказа
Договор или отдельная возможность не активированы.

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

Ошибка 404 Not Found

Проверьте:

Версию API
Адрес метода
Идентификатор объекта
Рабочую или тестовую среду
Наличие лишнего символа в адресе
Не используется ли устаревший путь API 1.5.

Ошибка 429 Too Many Requests

Если сервер сообщает о слишком большом количестве запросов, необходимо снизить нагрузку.

Что помогает:

Кеширование справочников
Экспоненциальная задержка
Очередь фоновых операций
Ограничение повторных запросов
Защита от повторной отправки формы
Сохранение токена до окончания его действия
Получение статусов по разумному расписанию.

Не нужно запрашивать список всех городов и ПВЗ при каждом открытии страницы, если эти данные можно сохранить и периодически обновлять.

Ошибки 500 и 502

Серверные ошибки могут быть временными.

Приложение должно:

Записать код ответа
Сохранить идентификатор запроса
Не создавать дубликат заказа вслепую
Повторить безопасную операцию через определённый интервал
Проверить, не был ли заказ фактически создан
Сообщить ответственному сотруднику о проблеме.

Особенно осторожно следует повторять запрос создания отправления. Сначала нужно проверить результат предыдущей попытки, иначе можно сформировать две накладные на один заказ.

Почему в кабинете нет раздела «Интеграция»

Если раздел отсутствует, возможны несколько причин:

Договор ещё не активирован
У сотрудника ограничены права
Открыт аккаунт физического лица
Используется устаревший кабинет
Для аккаунта требуется дополнительная настройка
Доступ оформлен на другой адрес электронной почты
Пользователь вошёл не под тем договорным аккаунтом
Интеграция находится в другом разделе нового интерфейса.

Сначала проверьте, отображаются ли в кабинете договор, данные компании и отправления.

Если нужного раздела всё равно нет, обратитесь к менеджеру или в техническую поддержку. Перед обращением подготовьте:

ИНН
Снимок экрана
Номер договора
Описание нужной интеграции
Адрес электронной почты аккаунта
Информацию о том, для какой системы требуются ключи.

Как безопасно передать ключи разработчику

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

Рекомендуемый порядок:

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

Пример файла переменных окружения:

CDEK_CLIENT_ID=ваш_идентификатор

CDEK_CLIENT_SECRET=ваш_секретный_пароль

CDEK_API_URL=https://api.cdek.ru/v2

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

Типичные ошибки интеграции после успешной авторизации

Даже если токен получен, система ещё может работать неправильно.

Неверный код города

Название населённого пункта не всегда достаточно. Для расчёта и создания заказа может потребоваться корректный код из справочника API.

Неверный код ПВЗ

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

Вес передан в неправильных единицах

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

Не указаны габариты

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

Неправильно указан плательщик

До запуска необходимо определить, кто платит за доставку:

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

Неверно передан наложенный платёж

Сумма заказа, объявленная стоимость и сумма, которую нужно получить с покупателя, выполняют разные функции. Их нельзя автоматически считать одним и тем же параметром.

Повторное создание заказа

Если сайт не получил ответ вовремя, это не всегда означает, что запрос не был обработан. Перед повторной попыткой следует проверить наличие созданного отправления.

Статусы обновляются слишком часто

Запрос статуса каждую секунду не ускоряет доставку. Он только увеличивает нагрузку и вероятность ограничений.

Что лучше – готовый модуль или собственный API

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

Готовый модуль подходит, если:

Нужен стандартный расчёт
Нет нестандартных правил
Требуется обычный выбор ПВЗ
Заказы создаются по типовой схеме
Бизнес не планирует глубокую доработку
Сайт работает на популярной системе управления.

Собственная интеграция нужна, если:

Есть несколько складов.
Нужны особые правила расчёта.
Используется самописная система.
Нужно массовое создание отправлений.
Заказы поступают из разных источников.
Используется сложная логика возвратов.
Требуется собственная обработка статусов.
Доставка связана с внутренней системой учёта.
В процессе участвуют несколько юридических лиц.
Готовый модуль не поддерживает необходимые операции.

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

Частые вопросы

Где взять API СДЭК?

Ключи API СДЭК создаются в договорном личном кабинете. Откройте раздел «Интеграция» и нажмите «Создать ключ». После этого появятся идентификатор аккаунта и секретный пароль.

Как получить доступ к CDEK API?

Заключите договор, получите договорный личный кабинет, создайте ключ в разделе интеграций и обменяйте client_id и client_secret на временный токен OAuth 2.0.

Нужен ли договор для API СДЭК?

Для полноценной коммерческой интеграции доставки нужен договорный аккаунт СДЭК. Именно к нему привязываются рабочие ключи, отправления и условия обслуживания.

Где ИП взять API СДЭК?

Индивидуальный предприниматель получает ключи в личном кабинете аккаунта, связанного с договором ИП. Порядок создания такой же – раздел «Интеграция», затем кнопка «Создать ключ».

Можно ли получить API СДЭК физическому лицу?

Обычный пользовательский аккаунт физического лица не предназначен для полноценной коммерческой интеграции интернет-магазина. Для регулярных бизнес-отправлений следует оформить договор на подходящий правовой статус.

Что такое Account в API СДЭК?

Account – идентификатор интеграционного аккаунта. При запросе токена его значение передаётся в параметре client_id.

Что такое Secure password?

Secure password – секретный пароль интеграции. При получении токена он передаётся в параметре client_secret.

Можно ли использовать пароль от личного кабинета?

Нет. Для API создаются отдельные интеграционные данные. Пароль пользователя от личного кабинета и client_secret выполняют разные функции.

Как получить токен API СДЭК?

Отправьте POST-запрос на метод /v2/oauth/token. Передайте grant_type=client_credentials, client_id и client_secret в формате application/x-www-form-urlencoded.

На сколько действует токен?

Срок возвращается в поле expires_in. Приложение должно ориентироваться на значение, полученное в конкретном ответе.

Нужно ли получать токен перед каждым запросом?

Нет. Токен следует сохранить на сервере и использовать до приближения срока его окончания. Запрашивать новый токен перед каждым методом нерационально.

Почему API СДЭК возвращает 401?

Чаще всего перепутаны client_id и client_secret, используется пароль от личного кабинета, выбрана неправильная среда, истёк токен или неверно сформирован заголовок Authorization.

Почему ключ работает в тестовой среде, но не работает в рабочей?

Тестовая и рабочая среды разделены. Проверьте адрес сервера, назначение учётных данных и то, где был получен токен.

Можно ли подключить API СДЭК без программиста?

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

Можно ли использовать одни ключи на нескольких сайтах?

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

Что делать, если раздел «Интеграция» отсутствует?

Проверьте, что вы вошли в договорный кабинет бизнеса. Если договор виден, но раздела нет, обратитесь к менеджеру или в поддержку СДЭК.

Где находится официальная документация CDEK API?

Актуальная документация размещена на портале разработчика СДЭК. Перед внедрением конкретного метода необходимо проверить его текущие параметры, обязательные поля и примеры ответов.