SuggestAPI Now Supports the HTTP QUERY Method

SuggestAPI now accepts the standardized HTTP QUERY method for full-search requests. Agents and applications can send structured JSON search parameters while clearly identifying the operation as safe and idempotent.

Search APIs have long forced developers to choose between imperfect options. A GET request communicates that an operation is read-only, but complex filters, lists, and search expressions can be difficult to encode in a URI. A POST request carries a JSON body cleanly, but the method does not tell infrastructure that the operation is safe to repeat.

The Internet Engineering Task Force addressed that gap in June 2026 with RFC 10008, The HTTP QUERY Method. The new Standards Track RFC defines an HTTP method that carries request content while retaining the safe and idempotent semantics expected from a read operation.

Today, we are announcing support for HTTP QUERY in SuggestAPI.

As a discovery platform for agentic commerce, SuggestAPI sits between agents, storefronts, and live catalog infrastructure. Supporting QUERY gives developers a clearer way to express structured, read-only search operations without changing the search backend underneath.

What is the HTTP QUERY method?

An HTTP QUERY request asks the target resource to process the enclosed content and return the result. The request body and its media type define the query, while the target resource determines the scope of the operation.

This may sound similar to sending search parameters with POST, but the semantics are different. QUERY is explicitly safe, which means the client does not request a state change to the target resource. It is also idempotent, so the same request can be retried after a connection failure without concern about partial state changes.

QUERY is therefore more than informal shorthand for “GET with a body.” It provides standardized semantics for a read-only request whose input belongs in the request content rather than the URI.

Why search needed another HTTP method

Simple searches work well as URI parameters:

GET /search?q=boots&limit=10 HTTP/1.1

Modern search requests are often more involved. An agent may need to submit nested filters, multiple product attributes, semantic intent, routing options, or a collection of identifiers. Encoding that input into a URI creates practical problems as requests pass through clients, proxies, gateways, and servers with different length limits. It also adds encoding overhead and makes query values more likely to appear in logs or bookmarks.

Many APIs use POST instead:

POST /query HTTP/1.1
Content-Type: application/json

{
  "query": "waterproof hiking boots",
  "filters": {
    "price": { "max": 200 },
    "sizes": [9, 10, 11]
  }
}

The JSON is easy to read and extend, but the method alone does not communicate that the operation only retrieves information. QUERY preserves the structured body while making the read-only contract explicit.

Using QUERY with SuggestAPI

SuggestAPI now accepts QUERY on the full-search endpoint. The JSON body follows the same request shape used by the existing POST /query integration.

curl -X QUERY "https://api.suggestapi.com/query" \
  -H "Authorization: Bearer $SUGGESTAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "index": "products",
    "query": "waterproof hiking boots",
    "rewrite": true,
    "cache": true
  }'

The response uses the same normalized SuggestAPI schema. SuggestAPI resolves the configured adapter for the requested index, sends the request to the appropriate search backend, and maps the results into a consistent format. See Bring Your Own Search for the adapter model.

Your existing search engine remains the source of truth. Adopting QUERY changes how the search operation is expressed over HTTP, not how your catalog is indexed or where checkout runs.

What developers gain

The practical benefit is a more accurate contract between the caller and the systems handling the request.

Structured input without an overloaded URI. Clients can send filters, arrays, and nested JSON without squeezing them into a query string.

Explicit retry semantics. Because QUERY is idempotent, clients can repeat the request after a connection failure without treating it like a potentially state-changing operation.

Clearer policy and observability. Gateways, logs, and security systems can distinguish a read-only query from a general-purpose POST, provided those systems recognize the new method.

A path to content-aware caching. RFC 10008 allows a QUERY response to be cached. The cache key must incorporate the request content and related metadata, which prevents two different query bodies from being treated as the same request.

That last point matters for search infrastructure. Caching a QUERY response is more involved than caching GET because the cache must read the request content before it can calculate the key. The standard enables this behavior, but actual caching still depends on the capabilities and configuration of each client, proxy, CDN, and origin server.

QUERY support will take time to spread

RFC 10008 is an official standard, but standards and widespread software support do not arrive at the same moment. Some HTTP clients, frameworks, proxies, web application firewalls, and API tools may not yet recognize QUERY or may reject an unfamiliar method.

For that reason, POST /query remains available. Both methods use the same structured request and return the same normalized response. Developers can adopt QUERY where the complete request path supports it, then retain POST as the compatibility option for environments that have not caught up.

This approach lets teams adopt the standard without turning protocol support into a migration project.

The Discovery Layer for AI Agents

AI agents need more than an endpoint. They need to discover the right capability, express a structured request, retrieve current information, and hand the result back in a consistent form.

SuggestAPI is building The Discovery Layer for AI Agents and an Agent Search Layer for live commerce. Our discovery platform connects agent intent to merchant-controlled catalog data while allowing merchants to keep the search engines, storefronts, and checkout systems they already operate.

HTTP QUERY strengthens that architecture at the request layer. Google’s Agentic Resource Discovery specification can help an agent find a capability. OpenAPI can describe the interface. The QUERY method gives a read-only search request accurate HTTP semantics. SuggestAPI then routes the request to the configured backend and returns a normalized response.

The result is a cleaner path from agent intent to live product discovery, built on open standards rather than one-off integrations.

Start using HTTP QUERY

Developers can begin sending QUERY requests to https://api.suggestapi.com/query using the same authentication and JSON body as the existing full-search endpoint. If any part of the request path does not yet support the method, switch back to POST without changing the payload or response handling.

You can review the HTTP QUERY standard, explore the SuggestAPI search architecture, or join the SuggestAPI waitlist to build agent-ready catalog discovery on top of your existing search stack.

Your search stack stays. Your checkout stays. SuggestAPI acts as the discovery platform and Agent Search Layer that makes your catalog discoverable to the agentic web.

References

1. RFC Editor, “RFC 10008: The HTTP QUERY Method”
2. SuggestAPI, “Bring Your Own Search”