Connections

Connect OTTO to AI: Query orders and product data in chat

Connect your OTTO seller account to an AI chat through Backlane and verify access with three small checks for the connection, products and orders.

First connect your OTTO seller account to Backlane, then connect Backlane to a compatible AI client. You need access to the seller account, the appropriate API permissions and an AI client that supports remote MCP with OAuth. Verify the setup in three steps: list the connection, retrieve a known SKU and read a small sample of orders. A successful sign-in alone does not confirm access to product data and orders.

The following prompts are templates for these initial checks. They have not been run against a seller account. The current setup steps and connection details are in the Backlane documentation.

What roles do OTTO, Backlane and the AI chat play?

OTTO Market provides your seller account data. The Backlane OTTO integration connects the authorised marketplace interfaces to your AI client. The AI chat receives your question, calls suitable tools and presents their responses.

The path is therefore: OTTO seller account → Backlane → AI client. MCP stands for Model Context Protocol and provides the interface between the AI client and Backlane. OAuth is the sign-in and authorisation process for this connection.

There are two separate authorisations: you allow Backlane to access your OTTO account, and you sign in to Backlane through the AI client. Signing in to OTTO in a browser does not automatically establish the second connection. Likewise, adding Backlane to your AI client does not create an OTTO seller account.

What do you need before setup?

You need access to Backlane, the correct Backlane organisation and an OTTO account with permission to authorise the integration. If you lack those permissions, the responsible person for your seller account must complete or authorise the setup.

The relevant OTTO interfaces must be accessible for the two data checks: Products for product data and Orders for orders. OTTO calls these permission areas “scopes”. They cover separate functions, so a successful product request does not prove that orders can also be read. The OTTO documentation on app permissions describes these areas and how sellers authorise a service provider’s app.

Your AI client must also support remote MCP with OAuth. Check whether this setup is available on your plan and in your workspace using the provider instructions linked from the setup documentation. Team workspaces may also require administrator approval.

Prepare a known SKU and a recent completed calendar day on which an order was placed. A SKU is your identifier for a specific product variant. Take it from your seller portal so you can match the response unambiguously later.

How do you set up the two connections?

First sign in to Backlane and select the organisation where you want to use your OTTO account. Choose OTTO and follow the connection dialogue for your seller account. Complete the required sign-in and authorisation steps.

Then connect your AI client to Backlane. Use the MCP server URL and the instructions for your client from the documentation. Complete sign-in with your Backlane account here too, and enable the connection for your chat if your client requires it.

Enter credentials only in the designated sign-in or connection dialogues. Do not copy passwords, API keys or tokens into the chat. Pasting the server URL into a message does not establish a connection; the URL belongs in the connection settings.

For your initial queries, you can disable write access across your Backlane organisation. That is the technical restriction. “Read only” in the prompts below further defines the task, but does not replace access permissions.

How do you verify access with three small queries?

First check that Backlane is reachable, then test product and order access separately. This helps you identify which step is failing.

A worked example: You sell lamps and want to check access before your first analysis. The SKU LAMP-BLUE is fictional; replace it with your actual identifier. In the seller portal, also select a day on which you know an order was placed. The following steps take you from setup to verifying those records.

1. Is Backlane reachable in chat, and is OTTO connected?

A successful call to list_integrations first confirms the MCP connection. The overview shows the integrations offered and which are actually connected. OTTO appearing in the list is not enough: check the reported connection state. If no marketplace account is connected, that is not an MCP connection failure. The setup guide explains the next steps.

Check my Backlane connection using read-only operations.
Call list_integrations for this check.

Distinguish offered integrations from connected accounts.
For OTTO, show the reported connection state and available
connection names. Show any supplied setup or repair link
if the integration is missing or broken.
Do not display credentials, tokens or internal identifiers.
If there are several OTTO connections, ask which one to check.

Expected result: a confirmed OTTO connection, no connected OTTO
account, a reported need for repair or a request error.
If an error occurs, do not ask for credentials in the chat.

For the lamp example, select an OTTO integration that is actually connected. Even this connection state does not establish that every OTTO interface is accessible.

2. Does the known SKU return product data?

Retrieving a single SKU checks product access and account selection. It avoids reading the entire catalogue just to test a connection.

In OTTO connection [connection name], read only the product
variant with SKU [SKU]. Do not change any data.

Show only SKU, EAN and product reference where available,
plus the source and retrieval time. Identify missing fields.

Expected result: a record that can be matched unambiguously,
or a clear message about no matching record, authentication
or authorisation. Do not invent replacement values or infer
a listing status from a missing match.

Compare the lamp’s EAN and SKU with your seller portal. A matching record confirms this product request. It does not confirm that the variant is online: the OTTO product documentation distinguishes submitted product data from marketplace status.

3. Can you read a small sample of orders?

One page containing at most three orders is enough for the next access check. Choose the day you prepared and filter by order date. OTTO distinguishes that date from modification and status timestamps; the order documentation shows dedicated date filters and the limit parameter.

Read orders from OTTO connection [connection name] for the
calendar day [YYYY-MM-DD] in Europe/Berlin.
State the exact time boundaries first.

Filter by order date using fromOrderDate and toOrderDate,
sort by ORDER_DATE and do not apply a status filter.
Read only one result page with limit=3; do not read further pages.

For each order, show a local row number, order date and each
item's SKU and fulfillmentStatus. Do not display names,
addresses, contact details or order identifiers.

Expected result: at most three orders, the retrieval time and
an indication of whether more result pages exist.
Label this as a sample without an overall count or revenue total.
Distinguish an empty result, missing access and a request error.

fulfillmentStatus describes the processing status of each individual order item. Compare the dates, SKUs and items with your seller portal. The order interface may also return buyer data; restricting the displayed output limits the chat response, not automatically the API response itself.

In this example, setup is confirmed for these tasks once the connection is reachable and both data requests work in a verifiable way. If the order check returns no matches, first check the date and connection rather than concluding that there were no sales.

What does an error or an empty result mean?

A request error, missing permissions and a successful request without matches are different findings. What matters is which step actually responded.

ObservationWhat is established?Next check
No Backlane tools in the chatThe connection check has not been performed.Check installation, sign-in and activation in the AI client.
Overview retrieved successfully, but no marketplace account connectedBacklane is reachable; offered integrations are not yet connected accounts.Check the active organisation and seller connection; use the supplied setup or repair link.
Sign-in failedThe affected request was not authenticated.Check whether the message came from the AI client or OTTO integration, and sign in again there.
Access deniedAccess to the requested data has not been granted.Check permissions for the affected interface.
Known SKU not foundNo product record was returned for this identifier.Check the connection and exact SKU.
Order request succeeded but is emptyThis specific query returned no matches.Compare the date boundaries, account and filters with the seller portal.

One more special case: opening the MCP server URL directly in a browser without signing in may return a 401 response. According to the Backlane documentation, this is expected and is not a useful connection test. Use a tool call from the signed-in AI client instead.

What should you do after a successful check?

Record the connection, SKU, date boundaries and retrieval times you used. This gives you a small reference for later checks without claiming to have performed a comprehensive analysis.

To check which order items are ready to ship next, use the prompt for OTTO items ready to ship. It requests all result pages without a lower date limit so that older open items are included.

For sales comparisons, continue with the practical guide to analysing marketplace data. If product data is accessible but the product is not visible, use the OTTO listing diagnosis guide. These business questions begin where the connection check ends.

Ask your own data the next question.

Connect your seller accounts with Backlane and use the available data in your AI assistant.

Set up Backlane