Provider setup reference

An owner or admin adds these providers in Settings → Integrations. Confirm the company and production/staging selection, open the provider tile, then choose Add beside each required field. Your provider administrator supplies credentials for the agreed account and permissions.

Save each value using Summer secrets manager. Selecting a provider records credentials; Summer still needs to verify its use in your company’s operational connection. A listed provider does not imply every provider operation is available to every company.

Required fields#

GEN Health#

Add the API key for your authorized GEN Health account. The portal email and password are optional, for a separately configured trusted browser sign-in. They are not needed just to save the API-key setup.

Confirm with Summer whether your workflow needs API reads, trusted portal access, or both. Optional portal credentials do not themselves provision a browser connection. Learn about the provider at GEN Health.

MD Integrations#

Add the matching client ID and client secret supplied for your MD Integrations account. Both are required. Check that they belong to the same environment and account; a partial pair leaves setup incomplete.

Confirm the records needed for your workflow with Summer. See MD Integrations for provider access information.

Beluga Health#

Add the API key for the Beluga account authorized for your company. During setup, verify that an intended visit or fulfillment record can be read and belongs to the correct patient and care episode. Missing results alone do not prove care or fulfillment never occurred.

For browser access, add Dashboard login key (BELUGA_DASHBOARD_KEY) in the same company and environment. The trusted sign-in process uses it at Beluga’s client dashboard, masks the login field and confirms visit search is available before handing the browser to the investigator. This is separate from BELUGA_API_KEY. UI-managed values and Doppler references use the same credential resolver; secret values are not returned to the agent. Missing credentials or unsuccessful sign-in remain visible access gaps. Successful sign-in does not approve visit changes or other business actions.

Provider information: Beluga Health. Clinician-chat referrals can instead use your own authenticated portal URLs without sharing this API key.

EasyPost#

Save the API key corresponding to the selected environment. EasyPost separates test and production keys; see its authentication guide.

Verify a known shipment or tracker needed for the workflow. Shipment lookup and a proposed shipping change are different operations. Saving a key does not authorize label purchases or other business effects.

Intercom#

Add the access token for the intended Intercom workspace. Confirm the conversation and shared-inbox permissions required by your agreed workflow with Summer. The setup tile does not select an inbox or automatically import all historical messages.

Use the Intercom developer documentation for provider-side access configuration. Verify one known conversation and inspect any history-coverage gaps before relying on search results. A conversation that is absent from saved history may still exist in Intercom.

Quo#

Add the API key for the Quo account whose phone conversations and text messages your workflow needs. Verify the intended phone number and one known record with Summer. A saved key does not automatically route inbound calls or enable outbound calls and texts.

Provider reference: Quo documentation.

Supabase#

Work with your database administrator and Summer to configure the dedicated operational reader:

• SUPABASE_READ_KEY: the dedicated operational read key. Do not use a service-role key.
• SUPABASE_READ_ROLE: the reader expects ops_agent_readonly.
• SUPABASE_READ_ONLY_KEY_SHA256: the SHA-256 fingerprint of the read key, attested by your database administrator.

The project URL, NEXT_PUBLIC_SUPABASE_URL, belongs to the trusted deployment configuration. Ask your Summer administrator to configure it; it is not another secret field in this tile.

Saving a role name and fingerprint does not prove the database enforces that role. Summer and your administrator must verify the actual grants and required reads. Keep database credentials out of knowledge examples. Provider reference: Supabase documentation.

Stripe#

Use STRIPE_READ_KEY with a restricted API key granting only the reads agreed for your workflow. Stripe’s API-key guide explains restricted keys and separate test/live environments. A publishable key or webhook signing secret is not a replacement for this field.

Confirm the account and environment, then verify a known billing record with Summer. This read credential does not enable refunds or subscription changes. Supported business effects retain their separate execution permissions and exact human approval.

Provider not listed?#

Use a custom integration to describe its credential fields, then agree the operational connection with Summer. For authorization failures or a saved key that cannot be used, follow Troubleshooting.

Confirm the connection works#

After saving credentials, use the agreed setup session with Summer to verify one known, authorized record. The integration tiles do not have a general provider test button. Use the source below to choose a useful check for your workflow.

Record which read succeeded and which permissions or history remain unavailable. Resolve missing access with your provider administrator and Summer before relying on the affected workflow. Business actions retain their separate review and execution process.