Skip to main content

Documentation Index

Fetch the complete documentation index at: https://archie.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

The GraphQL API Explorer is an in-browser IDE for querying and mutating your app’s data through the auto-generated GraphQL schema. Open any project, switch to the Backend Console, and you can build, test, and execute queries, mutations, and subscriptions against real data without leaving the workspace. The schema reflects your Data Model in real time. Add a table, add a field, or rename a column, and the corresponding GraphQL types, queries, and mutations regenerate immediately. API Explorer IDE overview with GraphQL editor

What’s in the Explorer

The Explorer ships with the four panels you’d expect from a modern GraphQL IDE:
  • Composer — a visual query builder. Pick a table, check the fields you want, and the Composer writes the operation into the editor for you.
  • Editor — the main code area. Write queries, mutations, and subscriptions with autocomplete, syntax highlighting, and inline error tooltips. Press Shift + Space to trigger the autocomplete menu manually.
  • Documentation panel — a searchable schema reference. Browse every query, mutation, type, and field in your schema. Click a type name in the editor to jump straight to its definition.
  • Results panel — the response from the most recent execution, with timing and error information.
API Explorer Composer with query results

Introspection and autocomplete

Because GraphQL ships introspection in the protocol, the editor knows your schema without any configuration. Start typing a field name and the autocomplete menu shows you the fields that exist on the current type. Hover a squiggly red underline to see why the editor thinks something is wrong — wrong scalar, missing argument, field not on type. API Explorer contextual auto-complete when typing in query

A single endpoint per project

Every project gets a single GraphQL endpoint that handles queries, mutations, and subscriptions for every table in the Data Model. Subscriptions use the wss:// variant of the same path. To target a specific environment, point requests at that environment’s endpoint — each environment has its own.

Authentication and permissions

Both happen at the API layer, not in the Explorer:
  • Authentication — every operation requires a token issued by an authentication provider configured in App Services → Authentication Providers. Inside the Explorer you’re already authenticated as your workspace user; outside it you’ll attach the token to each request.
  • Authorization — read and write rules per role are enforced on every query and mutation, configured in Role-Based Access. Operations that violate those rules return an authorization error.

Where to go next

Queries

Read records — single, list, filtered, paginated, sorted, aggregated, grouped.

Mutations

Create, update, and delete records, including bulk operations.

Subscriptions

Real-time event streams over WebSockets.

Standard operations

Filters, relationships, nested mutations, and upserts.

Variables

Parameterize operations with typed variables.

FAQ

It hits whichever environment is selected in the workspace. By default that’s the active environment for your project — typically master. To work against a non-production environment, switch environments before running operations.
Open the Documentation panel from the top-right toolbar, or click any type name in the editor to jump to its definition. Both list every query, mutation, subscription, and type generated from your Data Model.
The schema regenerates as soon as the Data Model changes, but the editor caches the schema. Reload the Explorer if a brand-new field doesn’t appear.
Copy the full operation and paste it into your teammate’s Explorer, or save it as part of your client code. The Explorer doesn’t currently persist named queries across users.
Both expose the same data, the same permissions, and the same auth model. GraphQL is best for nested reads, real-time subscriptions, and clients that want to fetch exactly what they need. REST is best when you want a familiar HTTP surface or are integrating with tools that don’t speak GraphQL. See the REST API Explorer for the REST equivalent.