Eva's API and what gets built custom

First capability: conversation. You send a message to the agent and get its reply, either in a normal call or streamed if you want to render the answer as it is written. It is the same machine that serves your channels, exposed to your own application.

Second: reading the conversation. You can fetch a thread's history and that thread's event list, which is the simple way to keep your interface in sync without standing up real-time infrastructure.

Third: receiving events. Each agent can have a signed outbound webhook, with a timestamp and an HMAC-SHA256 signature in the headers, so you can verify the event came from us and not from somebody else. If you would rather not expose an endpoint, the default alternative is polling the events yourself.

Fourth: sending an approved WhatsApp template from your systems. This is the one an ERP or a billing core uses to say something outside the conversation window: an order is ready, an invoice was issued, a payment landed. Meta approves the template; we dispatch it.

Two details worth knowing before you write code. Keys belong to an agent rather than to an account: one key resolves to one agent and only that one. And this surface does not extend into CRM, catalog, billing or administration: if you need that, the answer is not the public API, it is the primitives in the next section.

A connection to your API. You configure an HTTPS base URL with no auth, bearer-token auth or API-key auth. URL validation rejects unsafe or private-network targets, and that is not negotiable even when a customer insists.

Actions on your records. You define typed GET, POST, PUT, PATCH or DELETE calls against your API, bound to an Eva record, audited every time they run, and available as a button or as an automation on a CRM stage. It is what turns «move the card to Closed» into «create the order in your system».

Events going out. The generic webhook provider posts canonical CRM events to your endpoint, with an API key or bearer token if your side wants one. The same mechanism serves your own system or an automation tool's endpoint, but that is custom configuration rather than a named connector.

A catalog served by your API. A catalog can take your endpoint as its source instead of a file: you configure access, it resyncs on its own every twenty-four hours by default, and you can force a resync when you need one. It is the right route when inventory lives in your ERP and you are not going to export it by hand every week.

Per-agent HTTP tools. On top of all that, an agent can carry its own tools calling your endpoints with headers, query parameters, body templates and authentication. That is what lets it query your system mid-conversation and answer with your data rather than an invented one.

And here is the part almost nobody writes down: systems like CONTPAQi, Mercado Libre or your own ERP get connected custom, on these primitives, during implementation — they do not exist as one-click connectors, and anybody promising you otherwise is selling you smoke.

It is nearly always the same shape: catalog by API, actions and webhooks. Start with the catalog, because it decides whether the agent quotes your prices or invents them. Your system exposes an endpoint with products, prices and stock; Eva takes it as the catalog source and resyncs daily, and for the number that has to be exact right now you add an HTTP tool that checks live.

Then the action side. You define what Eva may write into your system and from where: a button on a CRM stage that creates the order, another that checks a shipment, another that records a payment. Each action is explicit and audited; nothing writes into your ERP because the model thought it was a good idea.

Close the loop with events. CRM events go out by webhook to your systems, and your core dispatches approved WhatsApp templates through the public API when something happens on your side. At that point there are no longer two worlds: the conversation across WhatsApp, Instagram, Messenger, calls, email and your site, plus Instagram comments and TikTok ad comments, and your system speaking the same language.

Order matters because the risk is not spread evenly. Catalog and read-only tools are tested quickly and corrected painlessly; the actions that write into your system are tested with test data and opened last.

Ask us to sort every system you mentioned into three buckets, unvarnished: native today, custom on the primitives, or not possible. If somebody hands you a list where everything lands in the first bucket, you are not reading a scope, you are reading a sales letter.

Ask us in writing what your side needs for the custom part to be possible: your API documentation, who authorises credentials, whether there is a test environment, whether the endpoint is reachable over HTTPS from outside, and what happens when your system is down. Without that, any estimate is a guess.

Ask us what we will NOT do. It is the part of a scope people skip most often and the part that costs most later.

And ask to see the primitive working rather than a slide. One real action against a test endpoint of yours is worth more than any catalog of logos, ours included.

• Bring your API documentation before the first technical meeting.
• Decide who on your side authorises credentials and a test environment.
• Confirm your endpoint is reachable over HTTPS from outside your network.
• Start with the catalog and with reads; leave writes for last.
• List the actions Eva will be allowed to run, one by one, and who authorises them.
• Decide whether you receive events by webhook or poll for them.
• Keep one key per agent and treat it as a credential, not as configuration.
• Ask for every system to be sorted into native, custom, or not possible.