Recover provider connections
Diagnose grant loss, refused reads, mapping problems and uncertain deliveries without repeating the wrong action.
Find the connection that needs attention, understand what failed and repair the intended account without repeating an uncertain action.
Start with the affected work#
Name the work you expected: read a calendar, book an agreed meeting, import contacts, send from an address or deliver an event to another application. A connection and a completed action are different facts.
Open the correct workspace. Keep the provider, account, time, exact error and last confirmed result together. If several accounts use the same provider, identify the one involved before changing anything.
Read CRM and integrations#
Open Settings → CRM and integrations. Read the relevant provider's status and account, then open its detail. A provider listed in the directory does not establish that every import, calendar action or write-back is supported or enabled.
If the directory could not be read, retry the read. Its current state is unknown. If a previously used account is unexpectedly missing or shown as not connected, compare its provider account and the current error before disconnecting it or replacing credentials. An empty or disconnected display alone does not establish why the account is absent.
For calendars, also read Settings → Calendar. For sending addresses, check the relevant channel settings. A healthy provider sign-in does not establish that a particular calendar or sender is selected for the intended work.
The integrations directory separates reported connected accounts from specific provider problems.
Choose the right recovery#
| What you observe | Useful next step |
|---|---|
| The page or provider did not answer | Retry the read and retain the error; keep current state unknown |
| A current error says the grant or sign-in has ended | Check the account identity, then use its supported sign-in flow |
| A key is refused | Verify the intended provider account and supported key before replacement |
| Connected, but a required field is missing | Inspect the supported mapping and destination requirements |
| Connected, but an import or delivery failed | Inspect that job or event's own recorded result |
| An earlier connect or save is unconfirmed | Re-read current state before another attempt |
Do not disconnect a healthy account to repair a timeout. A refused action can reflect missing permission, destination requirements or another problem even when the connection still exists. Use the exact error to choose the next step.
The Microsoft account detail asks for affected-job readback after connection recovery and does not promise automatic completion.
Reconnect the intended account#
Use the connection flow offered for that provider. For a sign-in provider, choose the intended account on its own trusted page and review the requested access. Opening that page does not finish the connection. Return to Kite and check the account and status it reports.
For a key-based provider, enter the value only in the trusted connection field. Do not paste credentials into a guide, public feedback, an agent prompt or a support screenshot. A key may allow access beyond the task you are trying to repair, so use the scope appropriate to that account and work.
Read the returned result. If verification failed or the connection is unconfirmed, preserve the message and check current state before retrying. Avoid revoking or replacing the previous provider credential merely because one response was uncertain.
Check the calendar after reconnecting#
Check the account, selected calendar, host, effective time zone and booking authority separately. Reconnecting does not move existing invitations or establish that an earlier booking succeeded.
A successful calendar check confirms the read or health result returned. It does not establish permission to create or move meetings. The Calendar event view can omit events; inspect the provider's diary before treating a time as free.
Use Set up and check booking for booking rules and offered-time checks. Test Zoom creates, moves and deletes a provider meeting, so run it only when you intend that actual test and have the required authority.
Calendar settings distinguish reported grant loss, a selected calendar and a shared calendar missing its host.
Check mapping and write-back separately#
Where the provider offers mapping controls, check the required destination fields and which Kite value supplies each one. Read the current write-back choices and the scope stated on the page. Some live connections use a fixed mapping rather than the editable controls available in other connections.
A reconnected provider does not prove that previously refused records were repaired or that historical events were replayed. Inspect the affected import or delivery. Do not turn on extra write-back, broaden permissions or map unrelated private data simply to clear an error.
For a partial import, follow Recover imports and sync. Check what was already written before bringing the source in again.
Read the Delivery log#
For API and webhook work, open Settings → API and its Delivery log. Check the event, destination, attempt time and result. Keep waiting, delivering, retrying, delivered and unknown outcomes separate. A queued retry has not reached the destination yet.
The current view shows a bounded recent window, up to 200 deliveries; delivery history has a 30-day retention window. An event outside that window or absent from this read is not proof it never happened. Use the destination's records or support when you cannot establish the result.
For an eligible webhook delivery, Send again is an action: it queues the retained original event. The supported retry requires a confirmed HTTP failure, the original event still available and an eligible original endpoint. It is not a general replay control for API requests or CRM writes. Do not replay an event whose outcome is unknown merely to see whether it works. A destination may already have processed an earlier attempt.
After an authorised replay, read the delivery's actual outcome and reconcile it with the destination. Do not create a new endpoint, rotate a key or send a different payload to imitate the original event.
The Delivery log shows retained recent outcomes and a reserved webhook destination; no replay is pressed.
Watch the recovery controls#
The walkthrough shows where to read a provider problem, check the account, inspect booking readiness and find an event's recorded result. Use the written decision steps before making a change. No connection or replay is completed by watching it.
Choose the right connection recovery
Work with your agent#
Ask for a diagnosis from the currently available authorised reads. Have the agent distinguish a failed read, a reported disconnected state, grant loss, missing action permission, a mapping problem and a failed job or delivery.
Keep credentials with you in the trusted product or provider page. The agent can return the affected account, known facts, unknowns, a supported recovery proposal and the exact review location. The public University endpoint provides guidance; it does not reveal or operate your private workspace.
A clear task to copy
Prepare a provider-recovery diagnosis. Discover the currently available authorised Kite tools and their exact argument schemas before reading account state. Use only supported reads in the correct workspace. Keep missing fields, failed reads and partial results unknown. Cite the current University guide, stable section and version. Public University tools supply guidance and do not reveal private account state or grant permission to act. Identify the affected account, intended work, exact error and last confirmed result. Separate unreadable state, reported disconnection, grant loss, missing action permission, required-field mapping and failed import or delivery. An empty/disconnected display does not establish that credentials are absent or why the account is reported disconnected or missing. A successful read does not prove write permission. Reconnecting does not prove earlier work completed. For delivery recovery, distinguish eligible webhook HTTP failure from unknown, pending or API/CRM results; inspect the retained original event and endpoint only if supported reads expose them. Never request or include credentials in the answer. Prepare only. Do not save settings, change permissions or credentials, connect or disconnect accounts, run provider tests, book or move or cancel meetings, approve requests, enroll people, import or re-read sources, pause or remove sources, replay deliveries, send messages, activate work or spend money. Return the exact in-app review location and a readback checklist for me.
This prepares guidance. Use the controls in your Kite workspace for account changes and starting work.
Before you move on#
Check the intended account and the affected work again. A recovered sign-in and a repaired action need separate evidence. Preserve unconfirmed results and the safe support context; use Get help with useful context when the current result cannot be established.
Your readiness check
0 of 6 checked
Your experience should make the next step clearer.
About this guide and its sources
Sources used to write and check this guide.
- Channels and connectionsChecked 2026-10-10
- Introduction delivery and next stepsChecked 2026-10-16
- Current connected Kite tool schemasChecked 2026-10-11
- Customer responsibilitiesChecked 2026-10-16
- Booking, provider and import recovery controlsChecked 2026-10-13