Test and publish a capability

A Draft capability isn’t callable by any specialist. Before you publish it, run a test to confirm the endpoint it calls actually works with realistic inputs and the credentials you supply.

Before you start

• A capability you’ve already created and saved as a Draft (see Create a capability)
• Sample input values that represent a real call — a real order number, a real customer email, etc.
• Access to the external API the capability calls (so you can verify the side effects, if any)

Steps

1. Open Settings → Capabilities and click your Draft capability.
2. Click Test in the editor header. (It stays disabled until the capability names a connection and an endpoint.)
3. Fill in the test input values. The Test endpoint dialog groups them the way the endpoint declares them — path, query and body — and marks the required ones. Below them, supply the credentials the test call should use.
4. Click Run test. Atender calls that endpoint directly with the values and credentials you gave it.
5. Inspect the result. The dialog shows:
   The HTTP status and the raw response body
   The request that was sent (expand View request details)
6. If something’s wrong — auth fails, the response shape is unexpected — close the dialog, edit, save, and run the test again. On the Advanced canvas the equivalent is the header’s Test button, which executes the capability and lights up the path it took through your nodes.
7. Review the go-live contract. Before publishing, the When this goes live card gives a plain-English summary of who can ask for the capability and what proof they need, plus an It will never list derived from the action tier, the connection, and the ownership settings. Use this to confirm the published behavior matches your intent.
8. Once you’re happy, click Publish in the editor header. While the publish checklist blocks, the button reads Publish — fix N items and pressing it jumps to the first failing row instead of publishing; on an already-live capability it reads Save & publish. Atender publishes once enrichment is complete, usage guidance is present, and the checklist passes. The capability is now live and can be added to specialists. You can also publish from the Capabilities list:
   Use the row-level Publish action for a single Draft capability.
   Select multiple Draft capabilities and use the floating bulk action bar to publish them together.

Verify it worked

After publishing, open Settings → Capabilities and confirm the capability shows as Published. The Used by column names the specialists that can call it; Not assigned there means it will never fire, so add it to a specialist (see Add a capability to a specialist). Then open that Agent Stack’s Testing tab and send a message that should trigger the capability — the specialist should call it and return real data in its reply.

If you need to take the capability offline, use Unpublish from the capability row in the Capabilities list. You can also select multiple published capabilities and use the floating bulk action bar to unpublish them together. Unpublishing returns the capability to Draft and disables the linked agent tool, so specialists can no longer call it until you publish it again.

Troubleshooting

• Symptom: The test run returns a 401 or 403. Fix: The authentication isn’t right. Open the connection and verify the credential, the auth type, and (if OAuth2) that the token hasn’t expired. For External OAuth, you’ll need to authorize as a test customer first.

• Symptom: The test returns the right HTTP response but the specialist sees nothing useful. Fix: Check the Response filter section — fields you did not allow through never reach the Agent Stack. Confirm the paths in the field tree match the response you just got back.

• Symptom: A canvas capability takes the wrong branch. Fix: Open the Condition node and verify the comparison operator and the value it’s comparing against. Edge cases like null vs. empty string vs. missing key are common gotchas.

• Symptom: Publish isn’t available or the capability doesn’t publish. Fix: Confirm enrichment is not still in progress and the capability has usage guidance. Atender only publishes capabilities that are finished enriching and include guidance that explains when the AI should use them. If the publish checklist shows blocked rows, click a row to jump to the relevant control. Atender scrolls to that control and tints it so you can fix the requirement in place. For connection issues on another page, the row deep-links to the connection pane. If the checklist shows Customers can sign in, the capability’s selected endpoint binds a customer field. Configure a supported customer sign-in path on the connection before publishing; don’t ask the AI specialist to supply that customer field.

• Symptom: A generated capability stays in Draft after generation. Fix: That is the design — nothing published in the UI publishes itself. Every surface that generates capabilities creates them as Drafts on purpose, so a human confirms the tier before anything goes live. Publish it from the review screen, the row action, or the editor.

• Symptom: The capability runs in test but specialists don’t call it in real conversations. Fix: Confirm the capability is Published, the specialist has been granted access to it (Settings → Agent Stacks → specialist → Capabilities), and the guidance clearly explains when to use it. The AI picks capabilities based on the description and that guidance, so vague ones get skipped. If the capability was unpublished, it returned to Draft and the linked agent tool was disabled; publish it again before testing with a specialist.

A note on test data

A test run goes to your real configured endpoint — there is no sandbox. If the capability writes data — cancels an order, charges a card — those writes really happen. Use a test endpoint or a sandbox API key whenever the API distinguishes one, especially for capabilities at the Act or Transact tier.

See also

• Create a capability
• Security levels reference
• Add a capability to a specialist