3. Configure your Agent

Configuration is where your agent becomes yours. You set three things: what it knows, how it behaves, and what it can do. You only need the parts your use case calls for — start small and add more as you iterate.

All configuration endpoints live under agent_config (and agent_connectors for actions), called through 360dialog with your D360-API-KEY. For exact routes and every field, see the Meta Business Agent API reference. One quirk to know up front: the list endpoints return bare JSON arrays, not a { "data": [ ... ] } wrapper — and settings comes back as a single-element array.

Endpoints can also fail intermittently with a 4XX or 500 for no clear reason while Meta debugs an ongoing instability — retry after a few hours before assuming your payload is wrong. See Known limitations.

---

Knowledge

Business info

Core facts about your business, stored as a fixed set of six fields. This is where the agent gets hours, policies, and contact details.

Business info is a closed object — you can't add custom keys. If a fact doesn't fit one of the six fields, put it in an FAQ or a file instead.

curl -s -X POST https://waba-v2.360dialog.io/agent_config/business_info \
  -H "D360-API-KEY: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "business_description": "Independent bicycle shop selling city, road, and mountain bikes, parts, and repairs.",
    "return_policy": "Unused items can be returned within 7 days for a full refund.",
    "delivery_and_shipping": "Free local delivery on orders over R$300; nationwide via Correios, 3–10 business days.",
    "payment_method": "Pix, credit and debit cards, and cash in store.",
    "purchase_info": "Buy in store or on WhatsApp. Reserve a bike with a 20% deposit."
  }'

PUT /agent_config/business_info

FAQs

Question-and-answer pairs the agent draws on. Each FAQ needs a question and an answer.

Keep FAQs focused, and don't overload. One specific topic per entry, phrased the way a customer would actually ask ("What is your return policy?" beats "Returns, exchanges, refunds"). Keep answers self-contained — the agent retrieves each entry independently, so don't reference other FAQs. Adding too many (beyond a few hundred) makes it harder for the agent to pick the right one. Prioritize your most common questions.

curl -s -X POST https://waba-v2.360dialog.io/agent_config/faq \
  -H "D360-API-KEY: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "What are your opening hours?",
    "answer": "Monday to Friday 9:00–19:00, Saturday 9:00–14:00. Closed Sundays and public holidays."
  }'

POST /agent_config/faq

Files

Upload documents (PDFs, images, etc.) as knowledge sources. Uploads are multipart/form-data, up to 100 MB per file.

File handling has real gaps today — read before relying on it.

• Uploads fail when a file name is included. Upload without setting a filename in the multipart part as a workaround.

• CSV files, and tables inside PDFs, error out when the agent tries to read them. Avoid tabular data in files for now; put critical structured facts into FAQs or business info instead.

• The agent can't reliably send files or images back out to customers. Don't design a flow that depends on the agent sharing a file.

We've raised these with Meta. Until they're fixed, keep files to plain-text-style PDFs and treat outbound file sharing as unavailable.

curl -s -X POST https://waba-v2.360dialog.io/agent_config/files \
  -H "D360-API-KEY: <YOUR_API_KEY>" \
  -F "file=@./return-policy.pdf"

Upload a knowledge file

Supported types: .pdf, .doc, .docx, .png, .jpg, .jpeg , .csv and .xlsx Maximum size: 100,000,000 bytes (100 MB).

Websites

Give the agent website URLs to crawl and reference. Add a url and the agent crawls it; the entry reports a crawl_status (e.g. pending, in_progress, completed, failed) and how many pages were crawled.

curl -s -X POST https://waba-v2.360dialog.io/agent_config/websites \
  -H "D360-API-KEY: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://www.example.com" }'

Add a knowledge website

---

Behavior

Skills

Skills are the agent's behavioral instructions — its tone, priorities, and brand voice. They're also how you teach the agent your processes: encode an existing business workflow (how you qualify a lead, take a booking, triage a support request) as ordered steps in a skill, and the agent follows it. This lets you reuse the processes you already run rather than inventing new ones.

Write skills as clear directives, and avoid conflicting priorities. The agent follows skills literally. If two skills both claim to go "first" on the same trigger, the agent can produce duplicate or inconsistent replies. When several actions should happen on one trigger, put them in a single skill with explicitly ordered steps rather than splitting them across skills.

Each skill has three parts:

• title — a short name, lowercase letters, numbers, and hyphens only (e.g. product-return-policy), max 64 characters.

• description — when to apply the skill (e.g. "Apply when the customer asks about returns or refunds"), max 1024 characters. The agent uses this to decide relevance.

• skill — the actual instructions, max 20,000 characters.

curl -s -X POST https://waba-v2.360dialog.io/agent_config/skills \
  -H "D360-API-KEY: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "polite-grounded-support",
    "description": "Apply to every customer message as the main support persona.",
    "skill": "You are the support assistant for our shop. Be warm, polite, and concise. Answer ONLY from the business info, FAQs, files, and tools provided. If the answer is not covered, do not guess — apologize briefly and hand off to a human. Never invent prices, stock, or policies."
  }'

Create a skill

Handoff

Handoff hands the conversation from the agent to a human. It's part of the agent settings object — set handoff.enabled and an optional message.

curl -s -X PUT https://waba-v2.360dialog.io/agent_config/settings \
  -H "D360-API-KEY: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "handoff": { "enabled": true, "message": "Connecting you to a human agent." }
  }'

Handoff behavior to design around:

• Once the agent hands a chat to a human, it stops answering that chat. A working human-handover path is essential — otherwise those customers get no replies.

• The handoff notice is the fixed message you define — it can't be adapted per customer language. For a multilingual audience, keep the message simple or language-neutral.

• On hand-back, the agent loses the earlier conversation context. Don't assume it remembers what was said before the human stepped in.

• There's no endpoint to read who currently holds the thread — infer it from the standby vs messages routing and the messaging_handovers events on your webhook. See Webhooks

Update AI agent settings

Follow-up

Follow-up sends a nudge after a period of customer inactivity. Also part of settings — set followup.enabled, a message, and followup_interval_in_seconds.

The interval must be one of: 0 (disabled), 300, 900, 1800, 3600, 7200, 28800, or 86400 seconds.

settings is a singleton (one per number) and is replaced with PUT. It also holds rollout (on/off) and ai_audience — the two levers you'll use in Go live and Roll out to everyone.

curl -s -X PUT https://waba-v2.360dialog.io/agent_config/settings \
  -H "D360-API-KEY: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "followup": { "enabled": true, "followup_interval_in_seconds": 3600, "message": "Is there anything else I can help with?" }
  }'

Update AI agent settings

---

Connectors and tools

Connectors let the agent do more than answer questions — they call your own APIs to look up an order, book an appointment, or check inventory. It's a two-level setup:

Write descriptions like you're briefing the agent. Give each connector and tool a clear name and description, and define the request body with explicit field types, descriptions, and required fields. Vague descriptions are the top cause of the agent calling a tool at the wrong time — or not at all. See the Meta Business Agent API reference for the full request_definition and user-auth injection schema.

1

Connector

Defines an external API: name, description, base_url, and auth_type. Supported auth types today are OAUTH2_CLIENT_CREDENTIALS, API_KEY, and NONE.

curl -s -X POST https://waba-v2.360dialog.io/agent_connectors \
  -H "D360-API-KEY: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Order Management",
    "description": "Looks up customer orders and returns status and tracking.",
    "base_url": "https://api.yourshop.example/v1",
    "auth_type": "API_KEY"
  }'

Create a connector

2

Connector tool

A single operation on that connector: name, description, and a request_definition. The agent reads these to decide when to call the tool and how to build the request.

# 2) Add a tool to it (use the connector id from the response above)
curl -s -X POST https://waba-v2.360dialog.io/agent_connectors/<CONNECTOR_ID>/tools \
  -H "D360-API-KEY: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "check_order_status",
    "description": "Use when a customer asks about an existing order. Requires an order ID. Returns status, estimated delivery, and tracking.",
    "user_auth_required": false,
    "request_definition": { "method": "GET", "path": "/orders/{order_id}" }
  }'

Create a connector tool

MCP connectors are not available yet. Support for MCP-based connectors is on Meta's roadmap (requested by many partners) but not shipped. For now, integrate via the REST connector model above.