Skip to content
BlendDesk

Integrations

One mechanism, and an honest list of what people build with it.

There is no logo wall on this page. BlendDesk connects to your systems one way: an HTTPS endpoint you control becomes a tool the agent can call, with declared inputs, a mock test and a person's approval on anything that changes state. Everything below says plainly whether it is live, something you build today, or planned.

What the labels mean

Live
Shipped, configured in the product, nothing to write.
Build it with a custom tool
No built-in connector. You point a custom HTTPS tool at your own endpoint; the mechanism is shipped, the recipe is yours.
Planned
Not shipped. On the roadmap, with no date we are willing to print.

The mechanism

Any HTTPS endpoint you control becomes a tool.

A custom tool is a declaration: a name the agent can reason about, a method, an endpoint, how to authenticate, and the inputs the agent must collect before it is allowed to call. Scout cannot invent a tool, cannot call one you have not attached to a scenario, and cannot change anything without a person approving it.

What the platform enforces

HTTPS only, and nothing on a private network
Plain HTTP is rejected and addresses that resolve to private ranges are blocked, so a tool cannot be pointed at something inside our infrastructure.
Size and time limits on every request
A slow or enormous response fails the tool call rather than hanging a conversation.
Credentials are write-only
A token you save is never shown again, in the UI or anywhere else.
Tested before it is live
Run a mock test with a sample response. A read-only tool can also send a real GET. Tools that change state cannot be fired as a test, because a test that changes a real order is not a test.
Changes wait for a person
Read-only tools run on their own. Anything that writes becomes an approval request with the exact operation shown to a reviewer.

How Scout uses tools

The tool definition

Tool name
Look up order
Stable identifier
look_up_order
HTTP method
GET
Authentication
Bearer token
HTTPS endpoint
https://orders.example.com/api/orders
Side effect
Read-only

Input parameters

NameTypeRequired
order_numberTextRequired

Illustrative demo with fictional data.

Shopify

The five jobs a Shopify merchant actually asks for.

There is no one-click BlendDesk app in the Shopify App Store. What there is, is a documented way to expose each of these as a tool against Shopify's Admin API or a thin endpoint of your own in front of it — and a clear line about the one that is not possible yet.

  • Order lookup

    Find the order from an order number, an email address or a phone number, and hand the agent back only the fields it needs.

    GET /orders · read-only · inputs: order_number

    Read-only, so it runs without an approval and the result is quoted in the reply.

    Build it with a custom tool
  • Order status and tracking

    Fulfilment state, carrier, tracking link and the delivery window, attached to the Order status scenario so the agent answers “where is my order?” from live data instead of a guess.

    GET /orders/{id}/fulfilments · read-only · inputs: order_number

    Pair it with a guardrail that asks for an order number first, so the agent never answers from memory.

    Build it with a custom tool
  • Delivery address change

    The most common pre-shipment request, and the one worth automating because the alternative is a customer calling after it has shipped.

    PUT /orders/{id} · changes state · inputs: order_number, address

    Writes, so it becomes an approval request. The reviewer sees the old address and the new one before anything moves.

    Build it with a custom tool
  • Refunds

    Issue, or more usefully, propose. The point of running refunds through here is that the proposal, the reason and the approver are all in the run record.

    POST /orders/{id}/refunds · changes state · inputs: order_number, amount, reason

    Writes and touches money, so approval is mandatory and a guardrail should block the agent from promising one in the meantime.

    Build it with a custom tool
  • Cart events into BlendDesk

    An abandoned cart arriving from Shopify as a trigger that starts a conversation.

    Inbound webhook from Shopify

    BlendDesk can send a webhook out from an automation today, but it has no inbound Shopify trigger. Cart recovery currently starts from your side, not Shopify's.

    Planned

Why it is built this way

A connector that holds your Shopify admin token and decides for itself what to call is a connector you cannot audit. A tool you declared, with the inputs you listed, pointed at the endpoint you chose, is one you can read in a trace afterwards. The cost is a configuration step; the return is that nobody has to trust us with a write scope we did not explain.

Other systems

ERP, CRM, and everything with an API.

The same mechanism, different endpoints. We are listing these as categories rather than as logos, because a logo implies a tested connector and we do not have one.

  • ERP

    Build it with a custom tool

    Stock on hand, order state, invoice lookup, delivery scheduling. Most ERPs expose a REST endpoint or sit behind one your team already runs; that endpoint is the tool.

    • Stock check before promising availability
    • Invoice lookup by order number
    • Delivery slot by governorate
  • CRM

    Build it with a custom tool

    Read the customer record so the agent knows who it is talking to, and write back the qualified lead when the conversation produced one.

    • Fetch account tier and open tickets
    • Create a lead from a qualification scenario
    • Attach a conversation summary to the record
  • Anything else with an HTTPS API

    Build it with a custom tool

    Booking systems, clinic schedulers, learning platforms, logistics providers, your own internal admin. If it answers an HTTPS request, it can be a tool.

    • Check an appointment slot
    • Look up a shipment with a courier
    • Query your own admin for an account state

Live connections

The integrations that are shipped and configured in the product.

These are not recipes. You connect them in settings.

  • WhatsApp Cloud API

    Through your own Meta business account and your own number, which is why Meta bills you directly for messages and we never mark that up.

    Live
  • Instagram

    Set up with our team. Availability depends on Meta's approval of your assets.

    Live
  • Messenger

    Set up with our team. Availability depends on Meta's approval of your assets.

    Live
  • Email

    Gmail, Microsoft or any IMAP provider. Scout does not auto-reply on email; Copilot drafts and a person sends.

    Live
  • Website live chat

    A script on your site. No platform approval needed, so it is usually the first channel live.

    Live
  • Outbound webhook events

    An automation rule can call your endpoint with Send Webhook Event, so your systems hear about a conversation without polling us.

    Live

FAQ

Questions about connecting things

Is there a Shopify app?

No. There is no BlendDesk listing in the Shopify App Store and no one-click install. Order lookup, status, address changes and refunds are built as custom HTTPS tools against Shopify's Admin API or an endpoint of your own in front of it.

Can Scout issue a refund on its own?

No. Any tool that changes state becomes an approval request. A reviewer sees the exact operation, can leave a comment, and chooses approve and execute or reject. There is also no built-in refund tool to approve — you connect your own.

What stops a tool from being pointed somewhere it should not be?

Only HTTPS endpoints are accepted, addresses on private networks are blocked, and every request carries size and time limits. Credentials are never displayed again after you save them.

Can we test a tool before customers see it?

Yes. Run a mock test with a sample response, and for read-only tools send a real GET. Tools that change state cannot be fired as a live test on purpose.

Do you have a public API?

Automations can send webhook events to your endpoint, which covers most of what teams ask for first. A documented inbound API is not something we are going to describe before it exists.

Bring the endpoint. We will write the tool definition with you.

A demo is the fastest way to find out whether your systems are a half-hour of configuration or a real project. We will tell you which, on the call.