Ідентифікатор облікового запису називає один підключений обліковий запис LinkedIn. Ви отримуєте його, коли вхід завершено, і підставляєте майже в кожен наступний виклик — у сегмент шляху, параметр запиту, поле JSON або поле multipart, залежно від операції.
Він непрозорий. Він не має префікса, це не UUID, і він не несе змісту, який варто було б розбирати. Поводьтеся з ним як із рядком, який ви зберігаєте й надсилаєте назад.
Чому він відповідає 404, а не 403
Кожен передплатник плану MakeHybrid API скеровується в один спільний тенант у зовнішнього постачальника, тобто ідентифікатори облікових записів усіх клієнтів живуть в одному просторі імен. Ніщо не доходить до цього постачальника з названим ідентифікатором, поки ми не підтвердимо, що його підключила ваша організація.
Промах відповідає 404, ніколи 403. Різниця — не ввічливість. 403 означав би, що ідентифікатор існує і не ваш, — отже, хтось міг би сидіти й генерувати ідентифікатори, відрізняючи справжні від вигаданих за тим, яка відповідь повернулася. 404 на обидва випадки не каже геть нічого.
Це перевіряється в усіх чотирьох місцях, звідки ідентифікатор може прийти: у шляху, у рядку запиту, у полі тіла JSON і в полі multipart. Ідентифікатор, що дійшов би до постачальника неперевіреним, був би читанням через межу чужого орендаря.
Часті запитання
Чи потрібно казати ШІ-агентові id облікового запису?
Він може знайти його сам. Асистент через MCP або ШІ-агент кімнати з позначеним MakeHybrid отримує список підключених облікових записів організації й бере account_id з відповіді. Зазвичай досить назвати обліковий запис звичайними словами.
Чи може ШІ-агент використати id облікового запису іншої організації?
Ні. Id перевіряється за організацією, якій належить ключ, і id іншої організації отримує від ШІ-агента відповідь 404 — достоту як від коду.