Skip to main content

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:

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

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

Sanitized response fragment:

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

Authorization header:

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:

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.