# Integrations and notifications

Alunta has several kinds of connections. A payment or accounting integration moves or synchronizes business data, a third-party app reacts through API and webhooks, Slack and email inform the team, and Radar provides signals about eligible business customers. Choose the workflow that fits the purpose.

## Activate a third-party integration

Open **Third-party integrations** or the marketplace, choose an app, and read which settings it requires. Activate it, complete the settings, and send a test webhook when the feature offers one. An app visible in the marketplace is not necessarily active for your team. After activation, edit settings or disconnect from the app page.

An owner or administrator can preview and send a connection test or deliberately choose a sample of one of the integration's events. The connection test is the default. Delivery runs in the background; wait for the HTTP result before assessing the connection. Samples use fictional resources and create no business data in Alunta, but the receiver may process the sample. Test deliveries are excluded from production health and failure alerts. Five test sends or replays can be accepted per minute per account; the marketplace receiver's capacity limit also applies.

## Slack and team notifications

Connect Slack, choose the workspace and channel the connected app can see and write to, and send a test. Then choose the events the team should receive. If a channel is missing, check channel access or whether the connection points to another workspace. Slack notifications are team messages; they are not customer emails or webhook events.

## Accounting and payment status

Accounting integrations such as e-conomic, Dinero, and Billy have their own document layouts and synchronization statuses. An error in the integration overview does not automatically mean an invoice is unpaid. Open the displayed error, follow the relevant guidance, and then check the document status. Not every error has a replay action.

## Radar

Radar checks relevant public company information for eligible customers. A signal is an observation that may need follow-up; it is not an automatic decision about the customer. Open the signal, read its history, and check the source before changing a subscription or contacting the customer. Informational findings can be stored without being sent as alerts.

## Help with a specific issue

**Get help** beside an integration error, webhook delivery, or invoice opens Support with a reference to the issue. From there, contact Alunta or take a prepared question to your own AI. If an AI connection is missing, setup continues on **My AI** with the reference retained. Connecting an AI is not required for personal support. On the Support page itself there is no area to choose. If you have a connected AI, you get one prepared question, and the AI looks across the relevant areas itself with the tools it has access to. "Get help" buttons placed on a specific area still carry that area.

When a question includes a support reference, the agent should first select the correct Alunta account and then call `get_support_context` with the full reference. A reference grants no additional permissions. The tool reads the current stored status and a limited explanation; it does not send raw error messages, webhook payloads, headers, or provider responses to AI. Follow the permitted tools and limitations in the result to investigate further. A general topic, such as health checks, is not a diagnosis of a particular incident.

Distinguish observed facts from possible explanations. An error that is not shown on the dashboard is not necessarily resolved, and stored information does not prove a provider's current state. If the reference can no longer be read, ask the user to reopen the issue in Alunta or contact support. The help flow does not retry payments or webhooks or change data.

## Common boundaries

A connection must be enabled and correctly configured for the specific team. A visible app is not the same as an active app. A test message or delivery log only shows that a message was attempted; your integration still needs to handle duplicates and failures. Check the team's current app status before building a workflow on a documented capability.