Build a custom HTTP tool

A custom HTTP tool is one you define yourself, pointed at any API you have. It exists for the systems Konvo does not integrate with natively, which for most stores means the one internal tool nobody else has: your warehouse, your booking system, your loyalty database.

You are not writing code, you are describing an endpoint: where it lives, how it authenticates, and what it expects to receive.

Before you start

Have four things to hand, because you will not get far without them: the endpoint URL, the method, how it authenticates (an API key or a bearer token), and what inputs it takes.

If you do not have these, whoever built or maintains that system does. This is the one page here where you may need them for ten minutes.

Create it

In your agent's Tools panel, choose Custom HTTP tool and fill in:

• Name. What the tool is called.
• Description. What it does and when to use it. Write this one carefully, because it is how your agent decides whether to reach for this tool at all. A vague description means a tool that never gets used, or gets used in the wrong situation.
• Method. GET, POST, PUT, PATCH or DELETE.
• Authentication. The key or token the endpoint needs.
• API URL. The endpoint.
• Input schema. The inputs it accepts, as JSON schema. Your agent fills these from the conversation.

The description is the whole game

Everything else here is mechanical. The description is what determines whether this tool is useful.

Write it the way you would explain the tool to a new hire who has never seen your systems. "Checks stock at the Barcelona warehouse by SKU. Use when a customer asks whether something is available for same-day pickup" is a description that gets used correctly. "Warehouse API" is not.

On or off, and nothing in between

Custom HTTP tools are on or off. There is no verification layer on them.

That is deliberate rather than an omission: the four verification modes exist for Konvo's own integrations, where we know what each action does and can guarantee what a check protects. With a tool you wrote, pointed at an endpoint we have never seen, we cannot make that promise, so we do not pretend to.

Which means the responsibility sits with you. Point a custom tool at something read-only and it is safe by construction. Point it at something that can change data, and your agent can change that data, so the guard belongs on your endpoint rather than here.

Test it before you rely on it

A custom tool is the one thing here that Konvo cannot verify for you, because only you know what your endpoint should return.

So run a simulation and watch your agent use it. Check what it does with a good response, and check what it does when the endpoint is unavailable, because that second case is the one your customers will meet on a bad day.

You can add as many of these as you need, each pointed at a different endpoint.