## Opening the project settings that control webhooks and automation
In Atloria, start from the **Projects** area and open the project you want to update. If you have already worked through [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options), return to that same project workspace rather than starting a new setup flow. From the project workspace, open the project’s **Settings** area, where Atloria groups together the controls that affect how the project behaves.

1. Open **Projects** and select the project you want to manage.
2. In the project workspace, go to **Settings**.
3. Look for the section that contains webhook and automation-related controls. On this page, Atloria may group these settings into areas for:
   - webhook configuration
   - project behavior toggles
   - connected workflow controls
4. Check whether the fields and toggles are editable. If you can only view the page and cannot change values or use **Save**, you likely do not have project administrator access.
5. Before making changes, review the current values so you know what is already active.

[SCREENSHOT: Project workspace with the Settings area open and webhook-related controls highlighted]

Some changes on this page take effect as soon as you click **Save**. For example, turning a project-level control on or off usually changes project behavior right away. Webhook event settings work a little differently: once saved, they affect future project activity that matches the selected events. They do not resend older activity automatically.

If your team uses connected workflows outside Atloria, pause before editing anything you do not recognize. A small change in the project’s webhook or automation settings can change whether external tools receive updates from this project. When in doubt, compare the current settings with your team’s expected workflow before saving.

## Entering webhook endpoints and delivery settings
Once you are in the correct **Settings** area, find the webhook configuration panel. This is where you tell Atloria where to send project event updates. The most important field is the webhook destination field, where you enter the endpoint used to receive outbound updates from Atloria.

1. In the webhook settings panel, click into the endpoint field and enter the destination URL.
2. Complete any security-related fields shown on the form. Depending on what your Atloria workspace displays, this may include a secret or token field used to secure deliveries.
3. Review the event selection area and choose which project events should trigger a delivery. Atloria may show these as checkboxes, a selectable list, or a multi-select control.
4. Confirm that every required field has a value before saving.
5. Click **Save**.

[SCREENSHOT: Webhook settings form showing endpoint field, security field, event selection controls, and Save button]

As you fill out the form, pay attention to inline messages under the fields. Atloria may stop you from saving if the endpoint format is invalid, if a required security field is empty, or if the same endpoint has already been added in a way that creates a duplicate entry. These messages usually appear directly next to the field that needs attention, which makes it easier to correct the problem without leaving the page.

If the page offers multiple event choices, select only the events your connected workflow actually needs. Sending too many event types can make downstream tools harder to manage. After saving, stay on the page long enough to confirm that the form no longer shows warnings and that the saved values appear in the webhook list or details area.

## Adjusting project controls that affect connected workflows
Webhook settings are only part of the picture. In the same **Settings** area, Atloria may also show project-level toggles and selectors that control whether automated updates are allowed, limited, or suppressed. These controls matter because a saved webhook endpoint will only receive updates when the project’s behavior settings allow those updates to be sent.

1. Review the toggles and selectors shown near the webhook settings.
2. Identify which controls affect outbound activity, connected workflows, or project automation.
3. Check each control’s current state before changing it.
4. Update the controls that match the workflow you want this project to follow.
5. Click **Save** if the page requires confirmation for the change to take effect.

[SCREENSHOT: Project settings page showing automation-related toggles next to webhook controls]

Atloria usually makes the state of each control visible in the page itself. An active control may appear switched on, highlighted, or marked as enabled. A disabled control may appear dimmed or switched off. If a setting cannot be changed, it may appear read-only. Some controls may not affect project behavior until you click **Save**, so watch for unsaved-change indicators before leaving the page.

These project controls directly affect downstream behavior. For example, if a project-level automation toggle is turned off, Atloria may stop sending updates even though the webhook endpoint and event selections are still saved. If a control is active, project actions that match your selected events can continue to trigger external notifications or connected workflows.

Because of that relationship, always review both parts together:
- the webhook entry itself
- the project-level controls that allow or restrict automated delivery

If your team reports that an integration stopped receiving updates, this settings page is the first place to check.

## Managing existing webhook configurations safely
You do not need to remove and recreate a webhook every time something changes. In Atloria, you can return to the project’s **Settings** page and update the existing webhook entry directly. This is the safest approach when you only need to change the endpoint, rotate a secret or token, or adjust which events trigger deliveries.

1. Open the project’s **Settings** page and locate the saved webhook entry.
2. Select the existing webhook configuration you want to update.
3. Edit the fields that need to change, such as the endpoint, security value, or selected events.
4. Click **Save** to keep the existing configuration and apply the new values.
5. Review the saved entry to confirm the changes appear correctly.

[SCREENSHOT: Existing webhook entry open in edit mode with endpoint and event options visible]

If you need to pause deliveries without losing the setup, use the available toggle or status control instead of deleting the webhook. A disable or off state is useful when you are troubleshooting, changing connected tools, or waiting for another team to finish setup. Later, you can return to the same entry and re-enable it.

When removal is necessary, use the delete or remove action shown for that webhook entry. Atloria may show a confirmation dialog or warning before completing the removal. Read that message carefully, especially if the page indicates the action is irreversible. Once removed, the project will no longer send future deliveries through that configuration.

After any change, check how the page displays the saved webhook. Atloria may show:
- a status badge
- an enabled or disabled state
- updated field values
- a last-updated detail

These on-screen details help you confirm which configuration is currently active before you leave the page.

## Reviewing validation messages and permission-related limits
When Atloria does not let you save a webhook configuration, the reason is usually visible on the page. The webhook form depends on required fields, and Atloria uses inline validation messages to point out exactly what needs to be fixed. Start by checking the fields that are essential for saving.

| Field or control | What to check |
|---|---|
| Endpoint | Must contain a valid destination URL |
| Secret or token field | Must be completed if Atloria marks it as required |
| Event selection | Must include the project events needed for delivery |

[SCREENSHOT: Validation messages shown under webhook fields after a failed save attempt]

Common validation states include an invalid URL format, a missing required value, or a warning that the same endpoint already exists. If Atloria rejects a value, the message usually appears directly below or beside the field. Correct that field first, then try **Save** again.

Permissions also affect what you can do on this page. Users without project administrator access may see the settings but find that fields are read-only, toggles cannot be changed, or the **Save** button is unavailable. In some cases, Atloria may hide certain controls entirely. If you expected to edit the page but cannot, compare what you see with another administrator or ask someone with project administration rights to confirm your access level.

Also pay attention to edit behavior:
- **Save** commits your changes
- **Cancel** discards the edits currently on the form
- unsaved-change indicators mean you have changed something but have not committed it yet

If you navigate away before saving, your edits may be lost. It is worth pausing for a final review before leaving the page.

## Testing the configuration
After saving the webhook settings, verify that the configuration works before you rely on it for live project activity. The simplest way to test it is to perform a project action that matches one of the events you selected in the webhook settings. This confirms both the webhook entry and the related project controls are working together.

1. Save the webhook configuration and stay on the project’s **Settings** page if possible.
2. Trigger a project action that matches one of the selected events.
3. Return to the webhook area and look for any delivery status, test result, or recent activity feedback shown on the page.
4. If Atloria offers a test delivery action, use it to confirm the endpoint is reachable.
5. Review the result and make changes if the delivery does not succeed.

[SCREENSHOT: Webhook settings page showing saved configuration and delivery status or test feedback]

If updates are not arriving, re-check the same items in this order:
- the endpoint URL
- the secret or token field
- the selected events
- any project-level automation toggle that could block outbound delivery

A webhook can look complete but still fail if one of those settings does not match the connected workflow. For example, the endpoint may be saved correctly, but no delivery will happen if the event you tested was not selected or if outbound activity is turned off at the project level.

If **Save** fails before you can test anything, read the field-level messages carefully. Atloria usually points to the exact problem. Also confirm that you have permission to edit project settings. A permission limit can look like a broken save process when the real issue is that the page is view-only for your account.

## Overview
This page in Atloria is for project administrators who need to control how a project sends automated updates to connected tools. The main work happens inside the project’s **Settings** area, where webhook configuration and related project behavior controls appear together. That layout matters because webhook delivery is not just about entering an endpoint. The project’s automation settings also determine whether Atloria actually sends outbound updates when project activity occurs.

Use this settings page when you need to:
- add a webhook destination for project event delivery
- secure deliveries with a secret or token field if shown
- choose which project events trigger outbound updates
- pause, re-enable, edit, or remove an existing webhook
- review validation messages before saving changes

This guide focuses only on the controls relevant to webhook setup and connected workflow behavior. It does not repeat the broader project settings and website options covered in [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). If you need help with general project setup, branding, or website-facing options, use that guide first and then return here to finish the automation-related settings.

As you work through this page, pay close attention to what Atloria shows after each change. Saved values, status badges, disabled controls, and inline warnings all help you confirm whether the configuration is active and whether your account is allowed to change it. For teams that depend on external notifications or automated follow-up actions, these details are important because a single toggle or missing field can change how the project behaves outside Atloria.

## Prerequisites
Before you update webhook settings in Atloria, make sure the project and your access are ready. This page is easiest to complete when you already know which project should send updates and which external destination should receive them.

You should have the following in place:
- access to the correct project from the **Projects** list
- permission to open the project’s **Settings** area
- project administrator rights if you need to edit fields, toggles, or use **Save**
- the destination endpoint value you plan to enter in the webhook settings
- any required secret or token value if your team uses secured webhook delivery
- a clear idea of which project events should trigger outbound updates

It also helps to have already completed the earlier project settings work described in [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). That earlier setup gives you the right project context before you start changing automation-related controls.

If you are preparing to test the webhook after saving, make sure you can perform at least one project action that matches the events you select. Without a matching project action, it is harder to confirm whether the webhook is working as expected.

Finally, if your team uses connected workflows heavily, review the current settings before editing them. Existing webhook entries, enabled toggles, and selected events may already support live processes. Careful review helps you avoid interrupting notifications or automation that other users depend on.

For the next part of project setup, continue with [Configuring Project Identity and Delivery Options](doc:configuring-project-identity-and-delivery-options).