Sending queries and responses

This page explains how to send an assembled query over HTTP and review the response and the error classification.

Overview

Sending is done as "the assembled query × the currently selected environment". Because HTTP communication is issued from the device side (GalleonQL itself), it is not subject to the browser's CORS restrictions. Even an internal API that a front end cannot access directly can be sent to, as long as GalleonQL's desktop process can reach it. The response can be reviewed in four tabs, and errors are classified and shown by their cause. For terminology, see Key terms.

Prerequisites

The destination environment is selected and the resolved URL is determined (you cannot send while unresolved {{...}} remain. Registering and switching environments).
You have added one or more root fields in the Query Builder (you cannot send while there are 0).
Schema import is not a prerequisite for sending (the send bar and response area are shown even without an import). However, assembling a query does require an import (Importing a schema).

Where it is on screen

The screen has three horizontal panes (left = request / center = response / right = schema). The left pane's tabs are Query | Auth | Headers. The send bar is on the left pane's Query tab, and from top to bottom the order is Query Builder → Generated Query panel → send bar (HTTP method selector + ▶ Send + status line). The response is shown in the center pane. The Auth / Headers tabs have no send button.

Steps

1. Prepare an environment and a query

Choose the destination environment in the top bar's environment selector, and confirm the resolved URL is shown (you cannot send while it is empty or has unresolved {{...}}).
If authentication is needed, set the default method and secrets in the environment editor's "Auth" section (Registering and switching environments).
If needed, check the Auth / Headers tabs (below).
Assemble the query on the Query tab (Query Builder). The contents of the Generated Query become the send body as is.

Auth tab (the request's authentication method)

Choose the authentication method on the left pane's Auth tab. Secrets (keys) are saved on the currently selected environment and do not leak into exports.

Option	Meaning
Inherit environment default	Use the selected environment's default method and secrets (the request's default)
Bearer	Build `Authorization: Bearer …` from the environment's Bearer token
Basic	Build `Authorization: Basic …` from the environment's Basic username / password

"Inherit environment default" shows no key input fields (keys live in the environment editor's "Auth" section). Choosing Bearer / Basic shows a key input field, and the entered value is saved as a secret of the currently selected environment. Choosing Bearer / Basic with no environment selected shows "Select an environment to enter secrets." Warnings such as empty token use the same wording as Registering and switching environments.

Headers tab (auth ON/OFF, request-specific headers, final preview)

At the very top of the left pane's Headers tab is a [✓] Use authentication checkbox.

ON … build the auth header (use the method from the Auth tab).
OFF … do not attach Authorization (the method is kept; turning it back ON restores it).

Below that, in the "This request only" section, you can add / edit / delete headers you want to put on this send only (source R). Enter a header name (e.g. X-Request-Id) and a value, then "Add header". You can write {{envVar}} in the value (resolved with the currently selected environment). At the bottom, "Final headers to send" shows the cascaded, variable-resolved result with source badges (see "Header cascade" in Registering and switching environments).

Request-specific headers, the auth method, the contents being assembled, and the HTTP method are auto-saved and restored on launch or when switching projects (they are not carried over when switching environments). The response body is not saved, and the Response pane is reset when you switch tabs.

2. Choose an HTTP method and press "▶ Send"

Choose the HTTP method in the method selector at the left of the send bar (default POST).

Method	How it is sent
POST	JSON body `{ "query": "..." }` (in Variables mode, `{ "query": "...", "variables": {…} }`) + `Content-Type: application/json`
GET	No body. The `query` parameter is URL-encoded and appended to the URL (in Variables mode, `&variables=<URL-encoded JSON>` is appended as well)
UPDATE	Same body as POST (`UPDATE` is not a standard method)
DELETE	Same body as POST (JSON)

When the Query Builder's input mode is Variables, the generated variables (JSON) are sent along too (in the body for the POST family, in the &variables= parameter for GET). In Inline mode, only the query body is sent as before and no variables are attached (see the input mode toggle in Query Builder).

{{environment variables}} written in argument values are resolved to the selected environment's values on send, for both the query body and variables (sending is not blocked even if unresolved keys remain; you only get a warning). You can check the resolved content with the Generated Query's "Final (resolved)" toggle, and the original {{...}} is kept as is in history and saved data (the {{...}} in headers and the URL are resolved the same way).

When you click ▶ Send, the label changes to Sending... and the button is disabled while sending. When a response returns, the status line shows HTTP {status} · {elapsed} ms (e.g. HTTP 200 · 1234 ms). If it fails before reaching the network, it is Failed · {elapsed} ms. When nothing has been sent, it is Not sent.

3. Review the response

To the right of the center pane's (Response) heading, meta information in the same format as the send bar is shown. Switch how you view it with the four tabs inside the panel.

Tab	Contents
Response	A collapsible tree with the body parsed as JSON (fully expanded by default)
raw	The body string received from the server, shown unmodified as is
Request Header	The headers actually used on send, shown with source badges
Response Header	All response headers shown (duplicates of the same name and receive order kept as is)

The "Response" tab toggles rows with ▼ (collapse) / ▶ (expand). When a new response arrives, it resets to fully expanded. A body that cannot be parsed as JSON is noted as "Cannot show a tree because it cannot be parsed as JSON. Check the original in the raw tab."
The Request Header source badges are A (App) / P (Project) / E (Environment) / Au (Auth) / R (Request) / unmarked (the Content-Type etc. synthesized on send).

4. Reading errors and partial errors

GraphQL can return errors[] even with HTTP 200. GalleonQL classifies and shows errors by their cause.

A full error (no successful data) is shown in red at the top of the Response as [category] message.

Category	Main cause
Network error	Connection failure, timeout, TLS/DNS, etc. — no HTTP response itself is obtained
Auth error	HTTP 401 / 403
Client (query) error	HTTP 400 and other 4xx, GraphQL validation/parse failure, a 2xx/3xx that is not valid GraphQL
Server error	HTTP 5xx, an internal resolver error, a response that cannot be parsed as JSON

Representative message examples:

Situation	Message
Auth failure	`Authentication failed (HTTP {status}). Check the environment's auth settings.`
Query problem	`There is a problem with the request or query (HTTP {status}).`
Server side	`A server-side error occurred (HTTP {status}).`
A 2xx/3xx that is not a GraphQL response	`Not a valid GraphQL response. Check the endpoint URL and path.`
Timeout	`The response timed out (no reply within 10s connect / 60s total).`

The timeout values are 10s connect / 60s total (fixed). Slow servers may take tens of seconds to respond.

A partial error (data and errors coexisting) keeps the data side in the tree, shows "Partial errors included:" in yellow at the top of the Response, and lists each error message (in the form message (CODE) if there is an extensions.code).

When you cannot send (guards)

When ▶ Send is disabled (dimmed), hovering the cursor outside the button shows the reason in a tooltip (when multiple apply, the single highest-priority one).

Priority	Tooltip text	What to do
1	`Sending…`	Wait for the previous send to finish
2	`No environment selected`	Add / select an environment (Registering and switching environments)
3	`Endpoint URL is unresolved. Check the environment request URL.`	Fix the environment's request URL and the referenced variables
4	`Query is empty. Add fields with add Query from the schema.`	Add fields with `+ query`

Sending example

Take the fictional schema type Query { hello: String } as an example.

Choose the destination environment in the environment selector (the resolved URL is shown in the top bar).
If authentication is needed, set the method and token in the environment's "Auth" section. The Auth tab can stay on "Inherit environment default".
Click the + query for hello in the right pane's schema documentation, and confirm the Generated Query becomes query MyQuery { hello }.
With the method left as POST, click ▶ Send.
It shows something like HTTP 200 · 42 ms, with the tree data → hello → "world" on the "Response" tab and {"data":{"hello":"world"}} shown as is on the "raw" tab.

Tips

The "Final headers to send" preview and the headers actually sent are always the same resolution result.
Request history can be reviewed from the history icon on the left rail (the latest 50 per environment). Clicking a row restores, in a new tab, the query, builder state, request-specific headers, HTTP method, and auth method (excluding secrets). The response body is not saved in the history.
Even if you switch environments while sending, an in-flight response will not overwrite the new state. Send again after switching.

Current limitations

Sending GraphQL variables follows the input mode. In Inline mode only the query body is sent (POST-family { "query": "..." }, GET ?query=...); in Variables mode variables are also sent (POST-family body { "query": "...", "variables": {…} }, GET &variables=<URL-encoded JSON>). For the input mode toggle, see Query Builder.
For a field with required arguments, set values in the Query Builder's argument input before sending. Sending it unset can cause a client (query) error on the server.
UPDATE is not a standard HTTP method. It fails on servers that do not accept it.
Authentication is None (none) / Bearer / Basic only (API Key, OAuth2 not supported).
The 10s connect timeout / 60s total timeout are fixed and cannot be set by the user.

When things go wrong

Symptom	Likely cause	What to do
`▶ Send` cannot be pressed	The guard conditions in "When you cannot send" above	Check the tooltip text and fix the environment / URL / query
`[Network error] The response timed out…`	The server is slow, or unreachable	Check the endpoint's availability and the network (a slow server may wait close to the full 60s)
`[Auth error] Authentication failed (HTTP 401). …`	HTTP 401 / 403	Check the environment's "Auth" section and the Auth tab's method. Also check whether `Authorization` (source `Au`) is in the final headers
`[Client (query) error] … (HTTP 400).`	Malformed query, missing required arguments, wrong path, etc.	Check the Generated Query and the argument input. Also check the URL's path
`[Client (query) error] Not a valid GraphQL response. …`	A 2xx/3xx that is not a GraphQL response	Check the endpoint URL and path (e.g. forgetting to append `/graphql`)
`[Server error] …`	HTTP 5xx, an internal resolver error, a non-JSON response	Check the server-side logs. See the original in the raw tab
`Partial errors included:` appears	`data` and `errors` coexist	Review the tree's data together with each error message
Nothing shows in the tree, only a pointer to raw	The body is not JSON	Check the original in the raw tab. Suspect the endpoint or Content-Type
UPDATE fails	The server does not accept the non-standard method UPDATE	Switch to POST