Skip to main content
@gojinko/api-client is the typed Node.js SDK for the Jinko Public API. It provides typed convenience methods for travel operations and a raw client for additional endpoints. Use an API key for new integrations; existing OAuth configuration is also supported.

Install

Works with Node.js ≥ 20. ESM-only.

Quick start

Authentication

createJinkoClient() resolves auth in this order:
1

Explicit apiKey option

2

JINKO_API_KEY env var

3

~/.jinko/config.yaml (CLI-shared)

The same config file the CLI uses. Run jinko auth login --key jnk_t_... to populate it; your scripts pick it up automatically.
If none of those yield credentials, createJinkoClient() throws AuthError.

Existing OAuth tokens

CLI OAuth login is deprecated. Use an API key for new CLI and SDK setups. If your config already has OAuth tokens, the SDK checks expiry before each request and calls the auth refresh endpoint transparently. Refreshed tokens are written back to ~/.jinko/config.yaml so long-running scripts don’t lose session.
You cannot paste an OAuth token directly into apiKey, different issuers. Use an API key (jnk_t_...) for programmatic access when you don’t want to maintain OAuth state.

Environments

Pass environment to target the sandbox (isolated data, separate API keys) before going to production:
Resolution precedence: the environment option → JINKO_ENV → the active environment in ~/.jinko/config.yaml (shared with the CLI via jinko config set environment sandbox) → prod. For a custom endpoint (such as dev/staging), set JINKO_API_BASE and use a key for that endpoint. This env var overrides the base URL even when you pass environment explicitly. Unset JINKO_API_BASE to use the environment URLs above. Sandbox flight tests: use Jinko Airline (ZZ). It is a fake airline that exists only in sandbox: search with include_carriers: ["ZZ"] on a route such as JFK–LHR from tomorrow onwards, and book flight ZZ101 for the normal flow. Every other flight number triggers one documented behaviour, such as a price change, a sold-out booking or a failed ticket, so you can test failure paths on demand. See Testing in sandbox.

The returned client

  • client.raw, the underlying openapi-fetch client, typed against the full OpenAPI spec. Use this when you need an endpoint not yet exposed via a convenience method.
  • client.auth, resolved credentials (method: 'api_key' | 'oauth', plus token info).

Error handling

HTTP failures throw ApiError; inspect statusCode to distinguish them. AuthError reports missing credentials during client setup, not an HTTP 401 response.
See Errors & troubleshooting for a full status code reference.

Observability

Every request the SDK emits carries:
  • X-Session-ID, stable per process/CLI session (from ~/.jinko/session.yaml)
  • X-Request-ID, fresh UUID per request; include it when you report a failure to Jinko
  • X-User-ID, only set on OAuth, from the JWT sub claim
The SDK sends X-Request-ID but does not log it automatically. After creating client, add this middleware before making requests to record the ID in your application logs:
Include the request ID when reporting a problem so we can trace it server-side. Log only the ID, not the full request headers or body.

Method reference

Convenience methods map to REST endpoints. Use the API reference for request and response schemas, and the booking guides for SDK examples. Endpoints without a convenience method are available through client.raw. Quick map: Click through any API endpoint for request and response schemas. See the booking guides for SDK and CLI examples.

Next steps

Booking guide

End-to-end booking flow in TypeScript, CLI, and MCP.

API reference

Per-endpoint request and response schemas.

Authentication

API keys, OAuth flows, and when to use each.

Errors

Status codes, error envelope, and debugging.