---
title: "Testing instructions"
description: "The public API Reference is read-only. Test Request stays hidden, and the browser guard rejects interactive requests before sending them."
canonical: https://docs.ordering.co/api-reference/guides/testing-instructions/
---

# Testing instructions

The public API Reference is read-only. **Test Request** stays hidden, and the browser guard rejects interactive requests before sending them.

This text-only replacement preserves the useful authentication and Postman workflow from the archived guide without restoring any of its seven rejected screenshots.

## Understand the localhost exception

When maintainers run the documentation on `127.0.0.1` or `localhost`, the local live-read mode can send only these allowlisted operations:

- `GET /configs`
- `GET /countries`
- `GET /ai/agents/{agent_id}/templates`

Those requests target `https://api.ordering.co` and can return production data. Do not activate **Test Request**, send a real request, or enter credentials unless the exact project, operation, and testing activity are authorized. Other methods and paths remain blocked.

No remote non-production sandbox is currently approved. CORS is not a safety boundary and does not prove that a request was not received.

## Bearer token workflow

Use a bearer token when an application acts for an authenticated user. In an authorized environment:

1. Prepare a `POST` request to the authentication operation for the intended project.
2. Send JSON with the user's email or cellphone and the required credential fields.
3. Read `session.access_token` from a successful response.
4. Send that token through the `Authorization` header on later requests.

Sanitized request shape:

```http
POST https://api.ordering.co/v400/en/YOUR_PROJECT/auth
Content-Type: application/json

{
  "email": "you@example.com",
  "password": "[REDACTED]"
}
```

Sanitized response fragment:

```json
{
  "error": false,
  "result": {
    "session": {
      "access_token": "[REDACTED]",
      "token_type": "bearer"
    }
  }
}
```

Authorization header:

```http
Authorization: Bearer YOUR_ACCESS_TOKEN
```

Bearer tokens and API keys are different credential types. Their permissions depend on the user, key, operation, and middleware; neither grants universal access.

## Prepare the same flow in Postman

You can configure the archived workflow in Postman without screenshots:

1. Create a request with method `POST` and the authorized authentication URL.
2. Under **Body**, choose raw JSON and enter only synthetic or authorized credentials.
3. After an authorized request succeeds, read `result.session.access_token` from the response.
4. For a later request, open **Authorization**, select **Bearer Token**, and enter `YOUR_ACCESS_TOKEN`.

Do not use an administrator account merely for convenience. Choose the least-privileged user that can perform the operation under test.

## API key workflow

Use a user API key only for an authorized server-to-server integration. Keep it in a server-side secret manager and send it through:

```http
X-Api-Key: YOUR_API_KEY
```

Do not paste a key into arbitrary endpoints. The key is revocable, inherits user-scoped permissions, and must be limited to the integration that needs it. This guide does not claim that a current dashboard screen exists or that keys have a permanent expiration policy.

In Postman, add `X-Api-Key` as a request header only for an authorized test, and use `YOUR_API_KEY` in saved examples. Never save a real key in a shared workspace, collection export, screenshot, or repository.

## Clear credentials

Scalar does not persist authentication. Reloading, navigating away, or selecting **Clear credentials** destroys the current in-memory Scalar session. This does not revoke a server-side token or API key; use the credential's authorized revocation flow when needed.

No request was sent while preparing this guide, and no Test Request control was activated.