Przegląd integracji

Zacznij od procesu

Otwórz Integracje, gdy wybierzesz proces w Kit i ustalisz, jakie dane lub działania muszą przekraczać jego granicę. Niektóre połączenia są opcjonalnym rozszerzeniem. Inne, na przykład wysyłka e-maili w Outreach, są niezbędne do przejścia całego procesu. Dashboard grupuje połączenia według zastosowania i pokazuje tylko karty pasujące do twojego konta, włączonych produktów i poziomu dostępu.

Potrzeba	Dostępne rodzaje połączeń	Czytaj dalej
Komunikacja zespołu	Slack, poczta przychodząca, SMS, rozmowy przez Twilio	Poziomy uprawnień Slacka
Planowanie terminów	Google Calendar i Meet, kanały kalendarzy, Calendly	Integracja z kalendarzem
AI w Kit	Google AI, Anthropic, OpenRouter, baza wiedzy	Dostawcy AI i limity wydatków
Zewnętrzni klienci AI	MCP Kit i zdalne serwery MCP przypisane do konta	Łączenie asystentów AI
Obsługa rekrutacji	Repozytoria GitHub do zadań i połączenia z portalami z ofertami	Konfiguracja repozytorium szablonowego GitHub
Operacje bezpieczeństwa	PagerDuty, Vanta, systemy śledzenia zadań, triaż uwzględniający kod	Integracja z PagerDuty
Tożsamość i domeny	Zweryfikowane domeny, SSO, automatyczne zakładanie kont, własne domeny	Jednokrotne logowanie i automatyczne zakładanie kont
Automatyzacja dla programistów	Tokeny API, webhooki, MCP, własne domeny	Dokumentacja API i Przegląd webhooków
Wideo	Mux dla obsługiwanych procesów w Hiring i Training	Skonfiguruj Mux z jego karty Integracji

Kto powinien połączyć system

Połączenia dotyczące całego konta zwykle wymagają administratora konta. Połączenia osobiste, takie jak kalendarz członka zespołu lub klient MCP, należą do tej osoby i pozostają ograniczone jej aktualnymi uprawnieniami w Kit. Połączenia właściwe dla produktu mogą dodatkowo wymagać dostępu do danego modułu lub roli administratora modułu.

Nie udostępniaj loginu dostawcy ani tokenu API jednej osoby tylko po to, żeby ominąć nadanie właściwej roli. Zaproś operatora, przyznaj mu najmniejszy potrzebny dostęp i pozwól połączyć system na przeznaczonym do tego ekranie.

Bezpieczna konfiguracja

1. Wskaż właściciela. Ustal, kto może zmieniać dane uwierzytelniające, reaguje na awarie i usuwa połączenie.
2. Wybierz najwęższe konto lub zakres. Na przykład zaznacz tylko kalendarze używane do rozmów i repozytoria przeznaczone na szablony zadań.
3. Przejdź weryfikację na żywo. Sam zapis danych uwierzytelniających nie oznacza jeszcze, że połączenie działa.
4. Wykonaj test wewnętrzny. Wyślij wiadomość na wewnętrzny adres, odbierz testowy webhook, utwórz próbne spotkanie albo użyj środowiska testowego, jeśli dostawca je udostępnia.
5. Sprawdź system odbierający. Poza Kit potwierdź tożsamość nadawcy, uprawnienia, strefę czasową, format danych i obsługę błędów.
6. Zapisz sposób odzyskania działania. Zespół musi wiedzieć, jak wykryje wygaśnięcie, cofnięcie dostępu, błąd dostarczenia lub awarię dostawcy.

AI, tokeny i webhooki

• Klucze dostawców AI są sekretami całego konta. Decydują, dokąd Kit wysyła żądania AI w aplikacji i które konto dostawcy zostanie obciążone.
• Dostęp MCP jest osobisty. Połączenie otrzymuje wyłącznie zakresy przyznane przez członka zespołu, a Kit sprawdza jego bieżące uprawnienia przy każdym wywołaniu.
• Tokeny API i sekrety webhooków to dane uwierzytelniające. Przechowuj je w menedżerze sekretów, przypisz im właściciela i zmieniaj lub unieważniaj, gdy zmienia się system odbierający.
• Webhooki są dostarczane asynchronicznie i mogą być ponawiane. Odbiorca musi weryfikować podpisy i bezpiecznie obsługiwać duplikaty zdarzeń.

Usuwanie połączenia

Przed rozłączeniem sprawdź, które procesy z niego korzystają. Usunięcie może zatrzymać nowe wysyłki, importy, spotkania, przesyłanie plików lub automatyczne działania. Nie wycofa jednak danych już przekazanych do innego systemu. Po usunięciu sprawdź zależny ekran w Kit i zmień dane uwierzytelniające po stronie dostawcy, jeśli mogły zostać ujawnione.

Checklist

• Zespół rozumie proces w Kit i dokładną odpowiedzialność połączenia
• Właściciel i wymagana rola w Kit są znane
• Uprawnienia po stronie dostawcy nie są szersze, niż potrzeba
• Wewnętrzny test przeszedł cały proces
• Odpowiedzialność za awarie i zmianę danych uwierzytelniających jest przypisana
• Skutki rozłączenia są zrozumiałe