Skip to main content
Two independent things gate an API call, and they fail differently:
There is no monthly request quota. Earlier versions of these docs described a “1,000 requests per 30 days” allowance per key. That model has been retired. Usage is metered in US dollars against your organization’s credit balance, and a cheap call and an expensive one no longer count the same.One exception: a legacy person-bound key — an older bare jnk_ key (no _t_) still accepted and tied to a user account rather than to a tenant — is still counted against a per-user allowance of 1,000 requests per 30 days, on top of the credit above. Every production tenant key is metered in dollars only. New keys from the dashboard or platform MCP get_api_key are tenant keys: jnk_t_ in production and jnk_sandbox_t_ in sandbox. Sandbox calls are not billed.

​
Credit

Credit belongs to the organization, not to a key. Every tenant and every API key under the organization draws on one balance, so spreading work across several keys does not give you more to spend. Calls are priced individually — a live provider search costs more than a cache read — so your balance moves by the value of what you actually called, not by a request count. The per-call price and this cycle’s usage are itemised on the Billing page.

​
Keeping live-search spend down

A live flight_search goes to the supplier on every call, in search mode and in price-check mode, and costs more than a cache read. Cached discovery (flight_calendar, find_destination, find_dates, lowest_fare) reads Jinko’s fare cache and costs less.
  • Explore with the cache. While the user is still choosing dates or comparing routes, use the discovery endpoints. Their prices can be 5-30 minutes stale, which is fine for browsing.
  • Go live once the choice is made. Call flight_search when the route and dates are fixed, or price-check the one itinerary the user picked by passing its id as offer_token. Do not price-check every calendar result.
  • Narrow before you go live. Apply the cabin, direct-only, time-of-day and price-ceiling filters on the cached call first, so the live call confirms a shortlist instead of building one.
  • Reuse a live result. A fare stays usable until its expires_at (at most 75 minutes from the search). Keep the response and serve repeat views, sorting and pagination from it instead of sending the same search again.
  • Search again only when you must: the fare’s expires_at has passed, the user changed the route, dates or travelers, or checkout answered OFFER_EXPIRED.
The current price of each call is listed on the Billing page. See Lifetimes and expiry for how long each result stays usable.

​
Included usage

Every plan includes an amount of usage each billing cycle. On the Free plan that is $5.00 per month, with no fee and no card required.
Included usage does not roll over. The grant covers one billing cycle and expires when that cycle ends. An unused $5 does not become $10 next month — every cycle starts at the plan’s amount, whatever you did or did not spend before it.
The dashboard shows your balance and the date the cycle resets.

​
Topping up

You can buy extra credit from the dashboard at any time, on any plan. Purchased credit is separate from the monthly grant and is not cleared at the cycle boundary. Included usage is always spent before purchased credit, so topping up mid-cycle never burns the free allowance you still had. To replenish credit automatically, set up Auto top-up.

​
Running out

When a call costs more than the organization’s remaining balance, it is refused with 402 Payment Required:
The message names what the call cost, what you had, and where to top up.
Do not retry a 402. It is deliberately not a 429. Retrying never fills a wallet, and an agent that treats this as backpressure will back off and spin quietly instead of telling you to add credit. Surface it to a human, or top up.
Your key stays active through all of this — a 402 is a billing state, not a credential problem. Nothing needs rotating, and the same key resumes working the moment the balance covers the next call.

​
Rate limits

Rate limiting is a separate axis from credit. Credit caps total consumption, not burst rate, so an organization with plenty of credit can still be throttled for calling too fast. The ceiling is a sustained requests-per-second rate with a short burst allowance. Whether a ceiling applies, and its number, is set for your organization as part of its plan or contract. It is applied per organization, so all of your tenants draw from one bucket. Credit works the same way: both are one shared organization allowance, so splitting work across tenants buys you neither more to spend nor more throughput. Over the ceiling, you get 429 and should back off:
Honour the Retry-After header when one is present; otherwise retry with exponential backoff. Unlike a 402, a 429 is worth retrying.
Throughput ceilings are set per organization and per contract, so they are not printed here — a number in a docs page would drift out of date. To find the ceiling on your organization, or to change it, email dev@gojinko.com.

​
See also