Guides & tools

Postman & OpenAPI

Import the OpenAPI 3 spec or the Postman collection to explore the API.

Two machine-readable artifacts let you explore and integrate without writing a line of code first: an OpenAPI 3 description and a Postman collection. Both are curated skeletons covering the authentication flow and a representative set of endpoints — enough to import, authenticate and start calling. For the exhaustive endpoint surface, see the API catalog.

Import into Postman

  1. In Postman choose Import and drop in grivaone.postman_collection.json (or paste the URL above).
  2. Open the collection's Variables tab and set email and password. Set companyId if your tenant has more than one company.
  3. Run Auth → Login. Its test script reads data.accessToken and stores it in the token collection variable.
  4. Every other request inherits Bearer {{token}} automatically — just send it.

Testing idempotent replay in Postman

The write requests set Idempotency-Key to Postman's dynamic {{$guid}}, so each send is a fresh operation. Replace it with a fixed value and send twice to see the 409 idempotentReplay response documented under idempotent requests.

Use the OpenAPI document

openapi.json is a standard OpenAPI 3.0 file. Import it into any compatible tool to browse the endpoints, or feed it to a generator to scaffold a typed client in your language.

shell · preview & generate
# Serve the OpenAPI document in a local Swagger UI with one command
npx @redocly/cli preview-docs https://developers.grivaone.com/openapi.json
# ...or generate a typed client from it
npx @openapitools/openapi-generator-cli generate \
  -i https://developers.grivaone.com/openapi.json \
  -g typescript-fetch -o ./grivaone-client

Its shape — bearer security plus paths — looks like this (trimmed):

json · openapi.json (excerpt)
{
  "openapi": "3.0.3",
  "info": { "title": "GrivaOne API", "version": "1.0.0" },
  "servers": [
    { "url": "https://gulfpay-production.up.railway.app/api/v1" }
  ],
  "security": [{ "bearerAuth": [] }],
  "components": {
    "securitySchemes": {
      "bearerAuth": { "type": "http", "scheme": "bearer", "bearerFormat": "JWT" }
    }
  },
  "paths": {
    "/auth/login": { "post": { "security": [], "summary": "Log in for a token" } },
    "/customers": { "get": { "summary": "List customers" } }
  }
}

These are skeletons, not the full surface

Both artifacts document the auth flow and a representative slice of the API so you can get moving quickly. They are not the exhaustive contract — always confirm behaviour against this reference and the API catalog, and watch the changelog for changes.