Create a capability

This walks through creating a new capability that calls an external API. The capability starts as a Draft, runs in a test sandbox, and is ready to be published once you’re happy with it.

Before you start

• A user role that can edit Capabilities (typically Admin)
• The base URL and authentication details of the external API you want to call
• A sample request that you know works — Postman, curl, or your engineering team can supply one

Steps

1. Open Settings → Capabilities.
2. Click New capability in the top-right.
3. Give the capability a clear name and description. The name is what specialists see when you assign capabilities to them, so make it task-shaped: Look up order, Cancel subscription, Track delivery. The description tells the AI when to use it.
4. Choose a build mode:
   Simple Tool — a single-form interface for “call this endpoint and return the result” capabilities. Pick this if your capability is one API call with no branching or transformation.
   Visual canvas — a drag-and-drop canvas for anything more involved (multiple calls, branches, loops). See Node types reference.
5. Configure the API. You can:
   Upload an OpenAPI (Swagger) spec — Atender parses it and creates endpoint definitions automatically.
   Provide a documentation URL — Atender reads the docs and builds endpoint definitions.
   Paste raw documentation — for APIs without a formal spec.
6. After Atender parses and saves the API definition, use Connect your account to add credentials. Atender seeds the fields based on the detected auth type: an API token for Bearer auth, an API key for API Key or Custom Header auth, username and password for Basic auth, and both token and key options when the auth type is unknown. Use Advanced settings to open the full authentication panel — auth type (API Key / Bearer / Basic / OAuth2 / Custom Header) and auth mode (External OAuth / Proxy Auth / Full Access / Custom). Choose Skip for now if you want to configure credentials later.
7. Define the inputs — the parameters a specialist must provide when calling the capability. Each input has a name, a type, and a description. The AI uses the description to decide what value to pass.
8. Define the outputs — the fields the capability returns to the specialist. Pluck from the API response and rename them so the AI sees clean, well-named values.
9. Set the security level and any identity verification you need (email, order number, zip code).
10. Click Save as Draft. You’re not live yet — Drafts aren’t callable from any specialist.

Verify it worked

You should see your new capability in the list at Settings → Capabilities with a Draft badge. Open it and confirm:

• The inputs and outputs match what you intended
• The authentication is set up correctly (the API connection test, if you ran one, should show green)
• The description clearly explains when the capability should be used

The capability isn’t usable yet — Drafts can’t be assigned to specialists. Move it through testing and publish it next.

Troubleshooting

• Symptom: The OpenAPI parser doesn’t pick up any endpoints. Fix: Check the spec URL is reachable from the public internet and that the file is valid OpenAPI (3.0 or 2.0). Paste the raw spec text into the editor as a fallback.

• Symptom: Authentication fails when you try a test call. Fix: Confirm the auth type matches what the API expects (Bearer vs API Key is the most common mix-up) and that the credential value doesn’t have whitespace or a wrapping "Bearer " prefix already in it.

• Symptom: The AI calls the capability with the wrong values. Fix: Improve the input descriptions. The AI picks values based on what each input means — vague names like id lead to wrong assumptions; descriptions like “The customer’s order number, e.g. ORD-12345” lead to the right ones.

See also

• Test and publish a capability
• Node types reference
• Authentication options
• Order lookup recipe