> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getnexor.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Advanced automation
The **Advanced** hub contains the capabilities for connecting Nexor to other systems, routing leads, and running automation outside the normal conversation flow. Open it from **Advanced** in the sidebar. Its configuration is organization-wide unless a tool is explicitly assigned to one agent.
Deliver signed events to an HTTP endpoint.
Let agents query APIs and take actions during a conversation.
Automate filtered lead cohorts with steps and safeguards.
Decide which agent receives a lead before a run starts.
Run JavaScript when a Nexor event occurs.
Run JavaScript over a lead cohort on a cron schedule.
Share write-only secrets with functions and tools.
## Choose the right capability
| Need | Use | Why |
| ----------------------------------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------------------- |
| Deliver a Nexor event to a service that already has an endpoint | Webhook | Sends a signed callback without running custom logic in Nexor. |
| Read or modify another system while the agent is talking | MCP Tool | The model decides when to call it and fills its arguments from conversation context. |
| Run a structured sequence over filtered leads | Background Job | Provides filters, conditions, actions, limits, and dry runs without writing a full program. |
| Route an inbound lead to one of several agents | Pre-processor | Evaluates ordered rules before creating the agent run. |
| Transform an event, call several APIs, or update a lead with code | Cloud Function | Runs isolated JavaScript with the complete event payload. |
| Periodically process a cohort with code | Scheduled Function | Combines cron, timezone, a lead query, and isolated JavaScript. |
| Store tokens, API keys, or URLs outside source code | Environment Variable | Functions read `env.NAME` and MCP tools resolve `{{env.NAME}}`; the UI never reveals the value again. |
These capabilities compose. A common pattern is **Pre-processor → Agent with MCP tools → Webhook or Cloud Function → Background Job for follow-up**.
## Webhooks
Webhooks send outbound HTTP notifications when a supported status, meeting, or outreach event occurs. Each request carries an HMAC signature in `X-Nexor-Signature`, allowing the receiver to verify that the payload came from Nexor.
Use a webhook when your system only needs the event. If you need to filter, transform, branch, call multiple services, or write data back to the lead, use a Cloud Function.
Before enabling a webhook:
1. configure its URL and events;
2. store the signing secret in the receiving system;
3. verify the signature against the unmodified body;
4. return a `2xx` response quickly; and
5. process idempotently because a delivery may be retried.
See [Webhook events](/docs/en/api/webhooks/overview), [Verifying signatures](/docs/en/api/webhooks/verifying-signatures), and [Retries and errors](/docs/en/api/webhooks/retries-and-errors).
## MCP Tools
An MCP tool describes an HTTP call the agent can make during a conversation. Its definition includes a name, description, method, URL, JSON parameter schema, headers, authentication, timeout, and response-handling rules.
**MCP Tools** in this hub let a Nexor agent call your systems. The [Nexor MCP Server](/docs/en/api/mcp-server) works in the opposite direction: it lets Claude, Cursor, Codex, or another AI client administer Nexor.
Tools have two scopes:
* **Shared catalog:** a reusable tool that can be assigned to several agents.
* **Agent tool:** a one-off integration available only to that agent.
After assignment, you can let the agent call it when needed, run it automatically when a lead enters, limit it to particular stages, or execute it automatically when a lead reaches a stage. See [Agent-level advanced settings](/docs/en/guides/agents/settings#agent-level-advanced-settings) for these policies.
An imprecise description or overly permissive schema can make the agent call a tool at the wrong time. Describe the effect, usage conditions, and every argument; store credentials in **Environment Variables** and reference them as `{{env.MY_KEY}}` instead of embedding secrets in the definition.
To manage tools through the API, see [Client Tools](/docs/en/api/client-tools/list-client-tools) and [Workflow Tools](/docs/en/api/workflow-tools/list-workflow-tools).
## Background Jobs
Background Jobs run structured automations over leads. They can be triggered by **cron**, by a **supported event**, or only through the **API**.
A job combines:
* filters by agent, status, and lead data;
* conditions on metadata, variables, or tags;
* actions such as assigning or transferring an agent, changing status, sending a WhatsApp template, or calling an external API;
* per-cycle lead caps, cooldowns, and rate limits;
* exclusions for human-taken-over leads or paused agents;
* dry-run mode and per-execution logs.
Start in **Dry run**, inspect how many leads would be candidates and which actions would run, then activate the job with conservative limits. Use **Run now** only after validating the same configuration.
See the [Background Jobs API](/docs/en/api/background-jobs/list-background-jobs) to create, run, and inspect jobs programmatically.
## Pre-processors
Pre-processors route leads before they enter an agent. Each processor has ordered rules and a default agent:
1. it receives a lead through the processor endpoint;
2. it evaluates rules from top to bottom using top-level fields and `metadata`;
3. it uses the first matching rule; and
4. it sends the lead to the default agent when no rule matches.
Use them to distribute by country, business line, campaign, product, account size, or any data available when the lead is created. The endpoint also accepts batches; each lead is evaluated independently and can reach a different agent.
See [Create a Pre-processor](/docs/en/api/processors/create-processor), [Create a rule](/docs/en/api/processors/create-rule), and [Route a lead](/docs/en/api/processors/route-lead).
## Cloud Functions
Cloud Functions run isolated JavaScript when an agent event occurs. Code receives the payload in `ctx`, can inspect `lead`, make requests with `axios` or `fetch`, write logs, return JSON, and propose changes with `updateLead` or `updateMetadata`.
Each function listens to one trigger. Simulate the payload, save to deploy, and inspect executions before activating it. HTTP calls made by a manual test are real even though proposed lead changes are not applied.
See the [complete Cloud Functions guide](/docs/en/guides/advanced/cloud-functions) for triggers, runtime, limits, examples, and logs.
## Scheduled Functions
Scheduled Functions run isolated JavaScript on a cron expression and timezone. Each execution queries a lead cohort, exposes batch context to the code, and records its result and logs.
Use one when the logic is too specific for a Background Job: aggregations, custom payloads, coordinated calls to multiple APIs, or rules that are clearer in JavaScript. Before enabling a function:
1. define the cron and timezone;
2. narrow the query to the required cohort;
3. preview the included leads;
4. test with safe credentials and endpoints; and
5. inspect logs and design writes to be idempotent.
A Background Job expresses filters and steps in a managed structure. A Scheduled Function gives you code-level control. Prefer the former when its actions cover the use case; use code for a custom transformation or integration.
## Environment Variables
Environment Variables store secrets shared by Cloud Functions, Scheduled Functions, and MCP tools. Functions read them as `env.NAME`, for example `env.CRM_API_TOKEN`. MCP tool authentication, headers, and query parameters reference them as `{{env.NAME}}`.
Values are write-only: after a secret is saved, the interface shows its name but never its value. Replacing a variable requires entering the complete value again. Names must start with an uppercase letter and contain only uppercase letters, numbers, and underscores.
Deleting or replacing a secret can break several functions at once. Search for the name in code, update the external system first when appropriate, and inspect deployments and logs after the change.
An organization can store up to 128 variables, with names up to 64 characters and values up to 5 KiB.