Skip to main content
Five endpoints power partner discovery: filter values for dropdowns, trim names for one model group, paginated list, single-vehicle detail, and lookup by VIN or license plate. For current production availability, common filter combinations, and pagination examples, see Partner vehicle search filters.

​
Brand-certified listing estimates

Live Encar vehicles with qualifying brand-certification evidence include a configurable addition in pricing.listing_price; the default is 4%. The same setting serves listing, ID detail and VIN/plate lookup. Auction and non-certified prices are unchanged. The addition increases only the listing component of estimated_landed; existing fees and discounts keep their amounts. pricing.brand_certified_pricing, when present, includes source_listing_price_usd, source_estimated_landed_usd, percentage and evidence. Those source amounts stay in USD even inside display_pricing. Search uses Encar’s Separation.F; detail uses Encar’s brand-partner evidence when no search-facet observation is available. These signals and observation times can differ. Certification is an Encar label, not an LMN inspection certification. price_min_usd and price_max_usd apply inclusively to the final rounded listing price. Price sorts merge the certified and ordinary searches before selecting a page. Price ties use adjusted native price, mileage, then vehicle ID. Price-sorted dealer searches accept up to four expanded make/model branches; omit make to search all makes through one branch, narrow the selection, or split larger requests. This limits concurrent branches, not inventory or page count. Existing mixed-source continuation restrictions still apply. Every dealer-inclusive search uses signed continuation cursors bound to the partner, environment and original query. They expire 24 hours after the first page and retain that search’s pricing percentage and FX. Keep following short/empty pages with a continuation. Retry a transient 503 with the same unexpired cursor; restart and deduplicate your accumulated results after expiry. At rollout, old dealer cursors return 400 validation_error with restart guidance. Auction-only cursor behavior is unchanged. Upstream inventory remains live: price or certification changes can move a car during a walk. A later detail request uses current settings and evidence, so it can differ from an older search. These amounts are listing-cost estimates. Order creation, negotiated purchase prices, settlement and order-time snapshots retain their existing pricing rules and can show different amounts. Source-price watch thresholds, Eagle Eye match/price-change webhooks, chat and MCP retain their source-price basis; a watch match can therefore exceed its source-price budget when viewed as an adjusted API estimate. Changing the surcharge does not create a source price-change event.

​
GET /v1/vehicles/facets

Returns the make, model, fuel, and transmission values you can send to GET /v1/vehicles.
Optional query: source (CSV) to scope the response to a source set. Add source=dealer to get the dealer (fixed-price) catalog; without source, the response describes auction sources and dealer together. source=auction selects all five houses (glovis, sk, aj, lotte, kcar); combining it with house names takes their union. Unknown tokens return 400 validation_error with details.field: "source". Tokens are case-sensitive. Illustrative response (selected makes and models only), with flat unique-value arrays — no per-value counts (UIs surface plain “Kia”, not “Kia (1,234)”):
The dealer-only facet correctly lists Encar’s eight fuel categories. This illustrative fuels array reflects the source-specific normalization now live in KR production as of 22:47 KST on October 20, 2026. See Partner vehicle search filters for behavior and environment caveats. Dealer vocabulary retains make/model/sub-model values from every Encar catalog LMN has served since August 11, 2026. A value remains after its last listing sells; removal requires an explicit catalog decision. Harvest runs on Monday at 04:43 KST, and the served vocabulary changes when a catalog is published. Mazda6 in the example is retained with catalog_status: "retired". Dealer vocabulary remains available while Encar is unreachable: described_sources still includes dealer, while sources omits it. Search results and stock remain separate from catalog status. An operator rollback to an older catalog can temporarily remove values first introduced after that version. If a newly started server cannot read the served catalog, it uses the committed retention floor; values first introduced after that floor may be temporarily absent until the read succeeds. Keeping a local catalog current. Pull facets?source=dealer once a day and compare makes, models, sub_models, and catalog_status with your copy; new entries and status changes appear when a new catalog is published and vocabulary_version changes. One pull covers all three catalog levels; trims come from GET /v1/vehicles/trims.
Before API 1.69 this endpoint listed only makes and models seen in auction inventory, even with source=dealer, and had none of the fields from described_sources down. A picker built from it was missing dealer-only makes (for example Mazda) and models (for example G-Class), and advertised auction spellings the dealer search rejects (for example EQS SUV, whose dealer model group is EQS).

​
GET /v1/vehicles/trims

Lists the English trim names that trim accepts for one make + model group, for dealer and auction listings alike. Never cached (Cache-Control: private, no-store).
  • make and model are both required, single values (no CSV, not All), spelled as for GET /v1/vehicles.
  • A supported model group with no trims — including truck models, which have no trim facet — returns 200 with trims: [].
  • Unknown or unsupported values return 400 validation_error with details.field (make or model) and details.value. Like the rest of /v1, this endpoint searches one Encar root per make, so Chevrolet model groups Encar lists only under its imported root (for example Silverado) return 400 on model.
  • While trim filtering is switched off, the endpoint returns 503 service_unavailable with details.reason: "trim_filter_disabled".

​
GET /v1/vehicles

Paginated, filterable inventory list. Returns VehicleSummary[].

​
Filters

Unrecognized query params are silently ignored. The server returns a 200 with default-filtered data instead of a 400. Common gotchas:
  • page / perPage — there is no offset pagination; use cursor + limit.
  • fuel_type — the param is fuel (singular). fuel_type is the BigQuery column name, not the API param.
  • transmissions (plural) — the FILTER param is transmission (singular). The plural form is the response field name in GET /v1/vehicles/facets.
  • result / status — use auction_status for auction result filtering.
  • seats / seat_count — use seats_min / seats_max (equal values for an exact count).
For a last-mile delivery use case, use:
body_style=van is currently a deterministic text heuristic over model/trim tokens (van, cargo, 2-seater, Korean 밴/벤) until upstream auction sources provide explicit seat/cargo metadata.If your client returns more rows than expected, double-check your param names against this table — the server isn’t filtering by something it doesn’t recognize.

​
Drivetrain filtering

Availability: Live in KR production as of October 20, 2026, 22:47 KST. The filter can be disabled for an environment during rollout or incident response; while disabled, requests carrying drivetrain return 400 validation_error. Requests without this parameter continue unchanged. When enabled, use two public groups; the response keeps the more specific source labels:
Values are case-insensitive (4WD also works). Comma-separated values use OR semantics; 2wd,4wd includes both known groups, while still excluding unknown or unrecognized drivetrain. No make or model is required. Invalid or empty group values return 400 validation_error. Auction and dealer rows are filtered by their drivetrain classification. Rows without a confident classification are excluded when a group is requested. Filtering runs before pagination. A dealer scan can exhaust its request budget before finding enough matches, so a filtered page can be short or empty while still carrying next_cursor. Keep following that cursor with the same filters until it is null; an empty page alone does not mean the search is exhausted. The existing mixed-source pagination rules apply. The response drivetrain field remains nullable and open-ended; typical labels are FWD, RWD, AWD, 4WD and 2WD. The filter groups do not replace those labels.

​
Search dealer inventory across all makes

Combine price, year, fuel, and body type without choosing a make or model:
For the next page, repeat the same parameters and add --data-urlencode "cursor=$NEXT_CURSOR", where NEXT_CURSOR is the response’s next_cursor. Treat it as opaque. A short or empty data array with a non-null cursor means keep paging; it does not mean no matching vehicles exist. See Price-sorted pagination for budgets, retries, and live-inventory limits. Build make/model pickers from Facets, including catalog_status: "retired" choices. Catalog presence and retirement are vocabulary states, not stock counts. Facets provides neither exact dealer totals nor counts beside each option.

​
Engine displacement

Use engine_cc_min and/or engine_cc_max with integer cc values. Both bounds are inclusive; equal bounds request an exact displacement. To include 1,998/1,999 cc cars in a nominal 2.0 L selection, send a 1,900–2,000 cc range explicitly. The API does not round or expand these bounds.
These filters work across auction, dealer and mixed searches without make/model. Blank, negative, fractional, non-decimal, unsafe-integer or reversed cc bounds return 400 validation_error with details.issues identifying the field. Liters are not accepted: 2.0 is invalid as a cc bound, and engine_l returns 400 validation_error instead of silently broadening the search. Missing or invalid source displacement is excluded when constrained. An explicit source 0 stays zero; missing values are never filled from fuel or a model label. Electric and hydrogen fuel-cell vehicles have no engine, so they never match a cc bound, whatever displacement value the source reports; hybrids and plug-in hybrids are filtered by their engine displacement, and the reported engine_cc stays as sourced. A zero-only selection is therefore not an EV filter. Source data can contain unit or classification errors; numeric presence does not certify displacement correctness. Use fuel=electric for the electric fuel category. Auction constraints run before pagination in the cache or BigQuery. Dealer searches preserve valid list-card cc and fill missing cc from the shared detail cache or a bounded detail refresh before applying the constraint. Scanning and final response mapping share one request-level refresh budget; unresolved values stay unknown. The same detail cc is available in unfiltered list responses. A dealer source whose summary has no displacement (currently Danawa) contributes no rows under this constraint. Coverage is incomplete, so this filter does not establish complete inventory counts. As of October 21, 2026, fewer than 1% of current auction listings had no known displacement (up to about 12% on October 20, before a source refresh fix); listings without a known displacement are excluded whenever a cc bound is set; dealer coverage depends on the displacement Encar provides in search and detail data. Keep the same filters while following next_cursor, including short or empty pages with continuation. Existing live-inventory and mixed-pagination limits apply.

​
Body-type filtering

Use body_type to filter auction or dealer listings, for example:
Values: compact, sedan, convertible, sedan_coupe, suv, suv_coupe, wagon, truck, van. Input is case-insensitive. Legacy aliases remain accepted: pickup → truck, minivan → van, coupe → sedan_coupe. SUV Coupe is a separate filter from SUV. Response labels are Compact, Sedan, Convertible, Sedan Coupe, SUV, SUV Coupe, Wagon, Truck, Van, or null when unresolved. Unknown body types do not match a body-type filter. Without this filter, unknown rows remain eligible. Auction filtering happens before pagination. Dealer body types are resolved after fetching each upstream window. With every sort the dealer side keeps reading until the page is full or its per-request budget runs out (see Price-sorted pagination and Dealer page limit), so a filtered page may be short or empty while next_cursor is present. Continue following that cursor until it is null. Dealer coverage is incomplete. Encar uses VIN/model lookups; model-specific public classification can fill known cases, while other unresolved rows remain null. The existing body_style=van text heuristic is separate from this taxonomy filter.

​
Location

Every vehicle carries a location object:
  • Terms. province is the 시/도 (one of Korea’s 17 first-level divisions) as its short romanized name: Seoul, Gyeonggi, Incheon, Busan, Daegu, Daejeon, Gwangju, Ulsan, Sejong, Gangwon, Chungbuk, Chungnam, Jeonbuk, Jeonnam, Gyeongbuk, Gyeongnam, Jeju. district is the 시/군/구 (city, county or district) inside it, with its suffix: Suwon-si, Yangpyeong-gun, Gangdong-gu. The same values are what the filters accept, case-insensitively, so a value from any row can be sent straight back as a filter.
  • Auction rows are located at the auction site: Anseong, Cheonan, Siheung, Seongnam, Incheon (Seo-gu), Yangsan, Osan or Sejong. Province and district are always present, except at Sejong: Sejong has no 시/군/구, so its rows carry province: "Sejong" and district: null, and the facets list for Sejong is empty. Dealer rows in Sejong carry the province alone in the same way.
  • Dealer (encar_*) rows are located at the dealer’s office. Search results carry the province only (district is null); GET /v1/vehicles/{id} adds the district from the office address. Encar files some Gwangju and South Jeolla dealers under one combined bucket: such a search row returns province: "Gwangju-Jeonnam", and the detail response resolves the real province. location is null for the rare row whose source has no location.
  • Filters. The province and district filters, location, and the facets provinces are available to every partner. province takes one or more names (OR, case-insensitive). Gwangju and Jeonnam each include the combined bucket; Gwangju-Jeonnam is also accepted and selects the bucket alone. district takes one 시/군/구 name (case-insensitive) and requires exactly one province, because Encar indexes one district inside one province. Dealer search rows returned under a district filter carry that district in location (every row is in it by construction; without the filter, dealer search rows have district: null). The valid district names per province are the provinces lists in the facets response; each province’s list holds the districts of its auction sites, plus the dealer districts from LMN’s weekly harvest of Encar’s region index. Before the first harvest, the list holds only the auction-site districts, and names from the built-in Korean 시/군/구 table are accepted; afterwards the harvested list is authoritative and an unlisted name returns 400 validation_error. The auction-site districts (for example Cheonan-si) are accepted for auction requests even when Encar indexes no dealer there; a request that includes dealer with such a district returns 400 validation_error. A district Encar files under the wrong province, or under its combined Gwangju/South Jeolla bucket, is listed only under the province it belongs to.

​
Seat-count coverage

Seat filtering is available in KR production as of October 20, 2026. Other environments may have it disabled; a disabled environment returns 400 validation_error for either parameter. Use seats_min and/or seats_max with integer seat counts from 1 to 99. Both bounds are inclusive; equal bounds request an exact capacity. No make or model is required.
  • Dealer seat buckets. Dealer (Encar) listings are classified into seat buckets: 2 or fewer, 3, 4, 5, 6, 7, 8, 9, and 10 or more. A seat filter selects the buckets inside your range, so it is exact only for bounds the buckets can express: seats_min 1 or 3–10, and seats_max 2–9 or omitted. With source=dealer or a mixed source, any other bound returns 400 validation_error with details.field, details.value, details.reason and details.dealer_exact ({"seats_min": [1,3,4,5,6,7,8,9,10], "seats_max": [2,3,4,5,6,7,8,9]}) instead of silently widening: seats_max=10 would include 11- and 12-seaters, and seats_min=11 cannot exclude 10-seaters.
  • seats_min=2 is an approximation. It selects the “2 or fewer” bucket, which can include single-seat vehicles.
  • Unbucketed listings are excluded. About 0.67% of Encar listings carry no seat bucket; any seat-filtered search excludes them. Danawa dealer rows carry no seat data and are excluded too.
  • Auction listings. An auction row carries a list of possible seat counts (seating_capacity_options) and matches when any of them lies in [seats_min, seats_max]; a missing bound is open. A model sold in several seat layouts therefore matches each of them: a 7-seat search can return a model sold as 5- or 7-seat, and options [5, 7] match seats_min=7&seats_max=7, seats_min=5&seats_max=5 and seats_min=6&seats_max=7, but not seats_min=6&seats_max=6. Auction rows with no known seat count never match a seat filter. Auction-only requests accept the full 1–99 range.
  • seating_capacity depends on the request. When seats_min equals seats_max and names one bucket from 3 to 9, every dealer row carries that value. Otherwise — a range, the open “2 or fewer” or “10 or more” bucket (including seats_min=10), or no seat filter — dealer list rows return null. Dealer values are never inferred from make, model, trim or body type.
  • Auction seating_capacity is published-only. It carries the seat count the auction listing published, otherwise null. Alongside it, seating_capacity_options lists the possible seat counts (sorted, [] when unknown) and seating_capacity_confirmed says how far to trust them: true when seating_capacity is published, false when the options are an estimate (a single estimated value or several candidates), null when nothing is known. Partners that need confirmed values should read seating_capacity or keep only rows with seating_capacity_confirmed: true. Dealer rows with a seat count return seating_capacity_options: [seating_capacity] and seating_capacity_confirmed: true; otherwise [] and null.
Blank, non-decimal, fractional, signed, out-of-range (0, 100) or reversed bounds return 400 validation_error with details.issues naming the parameter. Keep the same seat parameters while following next_cursor; existing live-inventory and mixed-pagination limits apply.

​
Model vs. sub-model

Korean inventory is organized in two levels: a ModelGroup (e.g. Cherokee) contains one or more Models (e.g. Grand Cherokee, Cherokee).
  • model selects the ModelGroup. model=Cherokee therefore returns every car in the Cherokee family — Grand Cherokee included.
  • sub_model narrows to a specific Model within that group: model=Cherokee&sub_model=Grand Cherokee.
sub_model is one scalar value; repeated parameters return 400 validation_error. Before auction taxonomy rollout, only dealer-only requests support it. Omitted source defaults to auction, so it also returns 400 validation_error rather than silently ignoring the child filter. Once rollout is enabled, sub_model requires one canonical make and one canonical model. Compatibility aliases are deduplicated before checking cardinality. Missing/multiple parents, unsupported children, and children under the wrong parent return 400 validation_error before source reads. Matching is exact: Grand Cherokee does not include Grand Cherokee (WL). Unknown or conflicting classifications are excluded from exact-child searches. trim remains an intersection with the selected child. Danawa is excluded from child-constrained requests. Parent alias migration: once enabled, model=Grand Cherokee selects the entire Cherokee group on both sources. To retain a generation-specific auction search, use make=Jeep&model=Cherokee&sub_model=Grand Cherokee or the corresponding qualified child. All mapped live rows then return model: "Cherokee". Discovering supported values: read sub_models[make][model] from Facets. English labels and documented Korean fallback labels are accepted as published. Once enabled, each live summary/detail/lookup also includes its evidence-backed sub_model; null means unresolved or unsupported. Once enabled, the sub_model key is present on every row (its value may be null); before enablement the key is absent. The value comes from the vehicle, not the request. Older immutable order snapshots may omit it and are never reclassified using today’s catalog. Planned dealer child aliases — not yet released: the behavior in this paragraph and table is prepared for a future production release. Today, send advertised model and sub_model values from facets; historical child aliases may still return 400, without suggestions. After release, a dealer model that is not a model group but names exactly one advertised child of the make is accepted as that child’s group plus sub_model. It matches when it equals one child’s label, or when its words are the leading words of exactly one child’s label (case- and accent-insensitive; spaces and punctuation count, so MX 5 is not MX-5). Retired children count, so a listed/retired pair is never resolved by guess. A value matching several children — in one group or across groups — is never guessed: it returns 400 validation_error with details.suggestions. With an explicit sub_model, the alias applies only when sub_model names the same child; otherwise the request is rejected on model with the aliased pair as the first suggestion. Rows still report model as the group and sub_model as the child. GET /v1/vehicles/trims applies no child aliases. Pagination: a taxonomy version change invalidates affected continuation cursors with 400 validation_error on cursor; restart from the first page. Mixed auction/dealer cursor pagination is available for price_asc / price_desc only — see Mixed source pagination.

​
Trim filter

trim narrows dealer and auction rows to the trims you name. Repeat the parameter or send a comma-separated list (trim=A,B) for several trims; a car matching any of them is returned.
  • English names, any spelling. Take values from trims[].label of GET /v1/vehicles/trims. Matching ignores case, runs of whitespace, brackets and the space inside a model code, so 3.0 LPI Taxi = 3.0 LPi (Taxi), GLE350d = GLE350 d and GLE 400d = GLE400d, and treats these as the same: 2.5 Turbo = 2.5T, Hybrid = HEV, LPG = LPI, AWD = 4WD = 4MATIC = xDrive, FWD/RWD = 2WD. Words must still be separated as listed: 2.0LPI is not 2.0 LPI.
  • Encode every value. Build the query with a URL encoder (URLSearchParams, curl --data-urlencode, urllib.parse.urlencode). A raw + in a query string decodes to a space, so 4MATIC+ must go on the wire as 4MATIC%2B.
  • Any source. trim works with source=dealer, with auction sources, with both (paginated with price_asc / price_desc, first page only with other sorts, as for every mixed request), or with source omitted. Omitting source searches auction listings only, as without trim; keep source=dealer (or source=dealer,<houses>) to get dealer rows.
  • One rule, both sources. A car matches when every word of the name is among what the car states. A dealer car states its Encar trim, so LMN sends Encar every listed trim that contains the name. An auction car states its title, plus the auction house’s engine size, fuel and drivetrain, plus engine words that virtually every Encar listing of the same model, year, engine and fuel carries (a 2022 G80 2.5 states Turbo even when its title says only 2.5). A broader name therefore returns the more specific trims that contain it: for a Lexus IS, trim=2.5 returns 2.5, 2.5 Premium, 2.5 F-Sport and other 2.5 … cars, and trim=Le Blanc on a Grandeur returns every Le Blanc, dealer or auction.
  • Auction titles are incomplete. A fuel or drivetrain word in the name (Diesel, 2WD) is waived when the auction car says nothing about it in its title or data, and enforced when it does. A car whose title and data contradict each other (title 2WD, data AWD) is not returned for names carrying such a word. About 95% of auction cars in models with trims are reachable this way (measured 2026-10-08); the rest name no grade in any source LMN has.
  • Scope. trim requires exactly one make and exactly one model group. Duplicates are collapsed, and whitespace around commas is ignored.
  • Limits. At most 30 distinct values across all trim params and list items, on every request. When source includes dealer, the trims sent to Encar after expansion must also fit 30 trims and 3,072 encoded bytes (too_many / too_long); auction-only requests are not subject to that.
  • Unknown or stale names. A name not listed for the model is accepted and simply matches nothing, on either source.
  • Encar only on the dealer side. A trim request returns Encar dealer rows only; source_status.danawa.status is not_requested.
  • One Encar root per make. As everywhere on /v1, Chevrolet model groups Encar lists only under its imported root (for example Silverado) are not searchable and return 400 validation_error on model, with or without trim.
  • Response rows. VehicleSummary.trim is the car’s English trim. It usually equals a listed name but can differ in spelling; build trim values from GET /v1/vehicles/trims.
  • Requests without trim are unchanged.
Errors. Every invalid selection returns 400 validation_error with details.field: "trim" and a details.reason; per-value problems also carry the offending details.value: While trim filtering is switched off, a request carrying trim returns 503 service_unavailable with details.reason: "trim_filter_disabled"; retry without trim, or later.

​
Sort

​
Price-sorted pagination

With sort=price_asc or sort=price_desc, dealer results (and mixed auction + dealer results, see Mixed source pagination) page by position, not by page number:
  • One stable order. Rows are ordered by price, then mileage ascending (cars without a mileage last within a price), then id (byte order). Many dealer cars share a price — about 1,300 list at exactly 9,900,000 KRW — and the upstream’s own order among them changes between requests; this order does not. Against stable inventory, a walk returns each matching listing once; see the live-inventory and twin-listing limits below.
  • Treat next_cursor as opaque and send it back unchanged with the same filters and sort. A cursor from a price sort sent with another sort returns 400 validation_error (details.field: "cursor").
  • Pages refill. The dealer side reads the upstream up to 6 times within a 10-second budget to fill limit rows after filters (transmission, body_type, contract hiding). When the budget runs out first, the page comes back short — possibly empty — with X-LMN-Page-Cut-Short: 1, page_cut_short: true in the body and a next_cursor that continues after every row already examined. Keep following it.
  • page_cut_short in the body. Every dealer or mixed page that carries X-LMN-Page-Cut-Short: 1 also carries "page_cut_short": true next to next_cursor; on other pages the field is absent. An empty or short page with page_cut_short: true and a next_cursor means the per-request budget ran out, not that inventory is exhausted; keep following the cursor.
  • body_type fills slowly. body_type is applied after each upstream window; with a make and no model, pages fill slowly until LMN enables model narrowing for that make and body type; make-free body-type searches always scan the full inventory in price order.
  • Retry the same cursor on 503. A later upstream read failure returns the page cut short with X-LMN-Page-Cut-Short: 1 and a next_cursor (and X-LMN-Partial-Dealer-Unavailable: 1); only a failure before any row was examined — or a budget that ran out before then — returns 503 dealer_upstream_unavailable, and your cursor stays valid.
  • make is optional. Without it the dealer side searches every make in one ordered query. A multi-value make or model keeps page-number cursors.
  • Limits. Inventory changes during a walk (cars sell and list continuously), so “every row once” holds against a stable inventory. Twin listings of the same car are collapsed within a page only; a pair split across two pages can appear once on each. A walk you started with an earlier page-number cursor continues on page numbers until it ends.
auction_date_asc (the default), year_desc and mileage_asc keep page-number cursors on the dealer side. The cursor also carries the IDs of the most recent 512 listings your walk returned or skipped as duplicates, so none of them is returned again, however far upstream changes move it. A longer walk can repeat a listing after its ID leaves the cursor’s 512-ID history. Because upstream ordering is live, a sale or reordering between requests can still cause an unseen listing to be skipped. Prefer sort=price_asc or price_desc for exhaustive traversal; their position cursors avoid offset shifts, while inventory and price changes can still affect completeness. Their pages also refill to limit (see Dealer page limit).

​
Null-strict semantics

When you filter on a field that’s null for dealer cars (accident_grade, auction_date_*, auction_count_*), dealer rows are silently excluded only when source is omitted entirely. The response includes an X-LMN-Filtered-Out: dealer=N header so your UI can tell the dealer “42 dealer cars were hidden”. When you explicitly request source=dealer together with one of these auction-only filters, the request returns 400 validation_error instead (see Dealer source constraints below) — fail-fast rather than silent drop. The header has two caveats, both consequences of dealer inventory being a live third-party proxy:
  • It only appears when make is provided. The excluded-count lookup runs only for requests that name a make; without make the header is omitted.
  • N is approximate and best-effort. It is the upstream match count for your non-auction filters; a small number of those cars may still have been narrowed further by response-side filters (for example transmission). If the dealer upstream is temporarily unreachable, the header is omitted rather than delaying your response.

​
Dealer source constraints

The dealer source is fulfilled by a live proxy to a third-party retail inventory (encar). Two design choices flow from that: make is optional: without it, source=dealer (alone or mixed with auction sources) searches every make in one upstream query. make may be a CSV list, for example Hyundai,Kia; the API fans out to one upstream dealer request per manufacturer. model requires make — model without make returns 400 validation_error (details.field: "make") — and may also be CSV; for dealer rows the API fans out valid make/model pairs, for example make=Hyundai,Kia&model=Avante,K5 becomes Hyundai Avante plus Kia K5 upstream searches. Vocabulary: make, model, and sub_model must resolve to LMN’s current dealer catalog, a documented compatibility alias — see Model vs. sub-model. Unsupported values return 400 validation_error with details.field, details.value, and (for model fields) details.make. This replaces the previous silent-zero fallback. Values are case-insensitive; the legacy Mercedes Benz spelling and audited Lexus forms such as ES350/RX350 remain accepted. Planned rejection suggestions — not yet released: after the upcoming alias release, a rejected dealer model or sub_model will also carry details.suggestions — advertised values to send instead — and details.facets, the facets path with the full vocabulary:
  • A model suggestion is a model group whose label starts with, or contains every word of, the value; or a model + sub_model child of a group that did not match. Values matching several children list those children first. At most 10, listed before retired, then by model and sub_model; each entry carries catalog_status as in facets.
  • A sub_model rejection lists every child of the resolved group (at most 25), so a misspelt child still sees the full set.
  • With multi-value make, a model that no selected make accepts is rejected with suggestions for every make, each entry carrying its make. A make that names nothing is omitted when another make accepts the value.
  • After that release, suggestions will always be present on these errors; [] means nothing matched — read models[make] and sub_models[make][model] from facets.
Forbidden: Combining source=dealer with any auction-only filter returns 400 validation_error. The offending field is reported in details.field: Filter parity gaps (dealer-only): A few filters supported on the auction side are silently dropped when applied to the dealer query because the upstream DSL doesn’t support them: keyword, body_style. The auction half of a mixed request still honors these. (Note: transmission is applied to dealer rows via a post-filter, color is honored as a single value, and options_include is applied natively — see below.) options_include for dealer: options_include is applied to dealer rows — it’s translated to Encar’s native Options. search DSL, with the same AND semantics as auction (a car must have all listed options). Two tokens are the exception: panoramic_sunroof and dashcam have no Encar filter equivalent, so a dealer request containing either returns 400 validation_error (details.field: "options_include", with the offending token named) rather than silently dropping it. This 400 is dealer-scoped — auction-only requests still accept every documented token — and is raised at validation time, so a mixed source=glovis,dealer request carrying one of these tokens returns 400 (not a degraded auction-only 200 with X-LMN-Partial-Dealer-Unavailable). Every other documented options_include token filters dealer rows normally. The full catalog of the 62 dealer-filterable tokens (and the 2 dealer-unsupported ones) is in options_include for dealer (full catalog) below. Under-contract listings are hidden. A dealer listing marked under contract on Encar (계약중 — a buyer has placed a deposit) is excluded from GET /v1/vehicles results while the contract is active, the same as a listing Encar reports SOLD or WAIT. Unlike those two, it’s reversible — LMN carries no special state for it, so if the contract falls through, the listing simply reappears in results on the next request. Detail behaves the same way; see the 404 note under Dealer detail caveats. Eagle Eye watches report this transition as its own removal reason — see Removal reasons.

​
options_include for dealer (full catalog)

Use the table below as the options_include token reference for dealer inventory filtering.
options_include is applied to source=dealer results server-side — each token is translated to Encar’s native option facet, so dealer rows are filtered at the source rather than after the fact. Multiple values are AND-combined: a vehicle must have all requested options to match. Tokens are case-insensitive snake_case (Sunroof, sunroof, and SUNROOF are equivalent).
Two documented option tokens are not available for dealer and return 400 validation_error (details.field: "options_include", with the offending token named): panoramic_sunroof and dashcam. Encar’s search filter exposes no facet for them. These two tokens still work for auction sources — the 400 is dealer-scoped (and applies to a mixed source=glovis,dealer request, since validation runs before the query fans out).
The 62 tokens below are all filterable for dealer, grouped by category. Column Token is the value you pass in options_include; Option is the human-readable equipment name.
Not available for dealer (→ 400): panoramic_sunroof, dashcam.
Auction sources currently support the original option set. Full parity for the newly-added dealer tokens on the auction side is a separate follow-up — for the auction half of a query, treat the tokens above as best-effort until parity ships.
Example — AND semantics across two options:
A car must carry every requested token to appear in the result — adding more tokens narrows the set, never widens it.

​
Mixed source pagination

Price sorts paginate across both sources. A mixed query such as source=auction,dealer&sort=price_asc (or price_desc, with make optional) returns one merged list in the price-sorted order — auction rows by their listed starting price, dealer rows by their asking price, both in KRW — with one next_cursor covering both sources. Follow it until it is null; against stable inventory, each matching auction and dealer listing is reachable once; listings, sales, and price changes during a live walk can still affect completeness.
  • If a later dealer upstream read fails, the page comes back cut short with X-LMN-Page-Cut-Short: 1 and a next_cursor that resumes both sources without skipping a row; only a failure before any row was examined returns 503 dealer_upstream_unavailable. Retry the same cursor.
  • While LMN refreshes its auction data, a mixed page can reflect the previous auction publication for up to 60 minutes after it loaded; after that, only auction data confirmed as the current publication is served, and the first request to a newly started server can take longer while auction data loads. If auction inventory is still unavailable, the request returns 503 service_unavailable. Retry the same cursor.
  • Auction rows with a starting price of 0 sort by that value (first under price_asc). Auction rows without a mileage sort after every row with a mileage at the same price; a real 0 km sorts first.
  • A multi-value make or model keeps the first-page-only behaviour below.
Other sorts are first page only. With auction_date_asc, year_desc or mileage_asc, a mixed query works on the first page and returns next_cursor: null; passing cursor returns 400 mixed_source_pagination_unsupported — paginate each source separately when iterating deeper than one page. When sort=auction_date_asc (the default), the response budget is split: half the limit is allocated to auction rows (sorted by date ascending) and half to dealer rows (sorted by year descending, since dealer listings have no auction date).

​
Dealer page limit

Dealer and mixed pages return up to the limit you request (max 200). The former 48-row dealer cap and its X-LMN-Dealer-Page-Max header were removed in v1.74. Every dealer sort fills the page from consecutive upstream windows of up to 48 rows, within the same per-request budget as price sorts (up to 6 upstream reads, 10 seconds; a multi-make or multi-model request spends one read per make/model pair on each window and always reads at least one window). When the budget runs out first, when one window of a multi-make request answers only partly, or when a later window fails, the page comes back short with X-LMN-Page-Cut-Short: 1, "page_cut_short": true in the body and a next_cursor that continues where it stopped; keep following it. An empty or short page with page_cut_short: true and a next_cursor means the per-request budget ran out, not that inventory is exhausted. If the first upstream read fails, the request returns 503 dealer_upstream_unavailable and your cursor stays valid. Twin listings of the same car collapse across the whole page, including rows from different upstream windows; a pair split across two pages can appear once on each. One exception: when Danawa listings are included in dealer results (source_status.danawa.status other than not_requested), a page-number page is filled from a single upstream window. body_type is applied after each upstream window; with a make and no model, pages fill slowly until LMN enables model narrowing for that make and body type; make-free body-type searches always scan the full inventory in price order.

​
Dealer upstream unavailability

The dealer half depends on external upstreams (Encar and Danawa). Every response where dealer inventory is explicitly requested includes a source_status object for Encar and Danawa. Each source is fresh, stale, partial, unavailable, or not_requested; as_of is the oldest evidence timestamp included for fresh, stale, or partial data. If live Encar search still fails after one retry, LMN may serve the exact matching cached Encar page when it is no more than 30 minutes old. Those rows are returned normally with source_status.encar.status: "stale" and the cached as_of. Treat them as last-known inventory and re-check live availability before relying on a vehicle. A multi-make/model query is partial when some Encar branches answer and others remain unavailable; its count covers answered branches only. When no eligible cache exists, two failure modes remain:
  • Pure dealer request fails (source=dealer only) → 503 dealer_upstream_unavailable only when every dealer source is down. If just one source fails, you still get a 200 OK with the surviving source’s rows plus the two degradation headers below.
  • Mixed request degrades (source=glovis,dealer with a sort other than price_asc / price_desc; price-sorted mixed requests return 503 only when the dealer upstream fails before any row was examined and otherwise come back cut short, see Mixed source pagination) → 200 OK with the auction rows (and any surviving dealer rows) plus two headers: X-LMN-Partial-Dealer-Unavailable: 1 — a binary flag (always the literal 1) signalling partial dealer degradation — and X-LMN-Dealer-Unavailable-Sources: <csv>, a comma-separated list of the failed or incomplete source names (encar, danawa, or encar,danawa). These headers are emitted for partial/unavailable, not stale. Check the flag for presence, read the source names from X-LMN-Dealer-Unavailable-Sources. The auction half is still authoritative; retry the named dealer source(s) via a separate source=dealer query when you need them.
The detail endpoint maps the same way: GET /v1/vehicles/encar_<id> returns 503 dealer_upstream_unavailable when the detail upstream is unreachable. 404 vehicle_not_found means the dealer listing is not currently available to buy: either the upstream explicitly returned 404 for that ID, the upstream detail page was still readable but marked the advertisement as SOLD or WAIT (both mean the listing is dead — Encar shows its own “sold or deleted” page for either), or the listing is under contract (계약중) on Encar — a buyer has placed a deposit but the sale hasn’t finalized — unless you have already created an order for that car, in which case the detail keeps resolving from your stored order-time snapshot (200) instead of returning 404, so a vehicle you’ve purchased survives delisting. The snapshot is scoped to your partner account and the key’s environment, so this recovery applies only to cars you ordered. Unlike SOLD / WAIT, an under-contract 404 is reversible — if the contract falls through, detail resolves normally again on LMN’s next check, with nothing to reset on your side. Dealer detail also attempts Encar inspection enrichment. When the inspection page is reachable, inspection_report is populated — dealer_inspection carries frame/exterior damage counts, body_condition.panels[] carries any damaged panels, and checklist[] carries the EN-translated mechanical inspection. A clean car returns a populated report with zero damage and a populated checklist (not null). inspection_report and body_condition are null only when Encar has no inspection record for the car (upstream 404). If the inspection, insurance record, history page or Encar Certified read fails transiently, detail returns 503 dealer_upstream_unavailable instead of a partial response — see Encar history and condition.

​
Response

Full Vehicle schema in Schemas.
id / vehicle_id values are auction listing IDs. They can change when the same physical car is re-listed in a later auction round. LMN matches same-car history internally by Korean license plate; use license_plate from the detail response when you need to identify the physical car.

​
GET /v1/vehicles/{id} — Detail

Returns the full Vehicle Detail — Summary fields plus VIN, photos, body condition diagram, full inspection report, and price breakdown.

​
ID format

The {id} path parameter is either:
  • An auction listing ID with one of the source prefixes: glovis_…, sk_…, aj_…, lotte_…, kcar_…. These are pulled from GET /v1/vehicles (the id field on each row).
  • A dealer (encar) listing ID with the prefix encar_<numeric>. Detail for dealer IDs is served via a live proxy to the upstream; expect modestly higher latency than auction detail.
The id you pass back must match exactly what GET /v1/vehicles returned. The auction-prefix IDs are not permanent physical-car identifiers — the same car may receive a different ID when re-listed in another auction round. Use license_plate on detail responses when you need the physical-car identifier.

​
Dealer detail caveats

Dealer detail responses differ from auction in three ways:
  • pricing.breakdown.auction_fee is 0; pricing.breakdown.dealer_fee is 300 (flat USD, not KRW-derived). pricing.discount_config.fixed_discount_amount is 300, which offsets the dealer fee so net economic impact on estimated_landed is zero — estimated_landed = listing_price + lmn_commission + ocean_freight.
  • pricing.auction_fee_config, pricing.market_assessment, comparables.past_sales, comparables.upcoming_sales, and pricing.history are all null or empty — these are auction-only concepts. (body_condition / inspection_report are populated for dealer when Encar has an inspection record — see the dealer-inspection note above; they are not auction-only.) pricing.discount_config is populated but the bid-based fields (bid_threshold, rate_below, rate_at_or_above) are all 0.
  • 404 vehicle_not_found is returned when the dealer listing is not currently available to buy: the upstream either explicitly returns 404, still serves a parseable detail page but marks the advertisement as SOLD or WAIT, or the listing is under contract (계약중) on Encar. Exception: if you hold an active or delivered order for that car, detail instead returns your stored order-time snapshot (200) and does not 404 — purchased vehicles survive delisting (snapshot scoped to your account + environment). That response carries a non-null order (buyable: false) and, once a purchase price is recorded on the order, pricing.listing_price is that price — see Schemas → order. A failed or cancelled order no longer keeps the snapshot: detail resolves from live inventory again (and may 404); use GET /v1/orders/{id}/vehicle for that order’s history. Under contract is reversible (unlike SOLD / WAIT): detail resolves normally again once the contract falls through, with nothing to reset on your side. Other failure modes (timeout, 5xx, unexpected response shape) surface as 503 dealer_upstream_unavailable so callers can distinguish “removed/sold listing” from “transient upstream issue.”

​
Response

Key nullables:
  • Unless explicitly documented otherwise, vehicle response monetary values are whole USD integers. This includes pricing, comparables, and inspection_report.accident_cost_summary.
  • pricing.breakdown.* fields may be null individually when a cost component isn’t yet finalized.
  • pricing.auction_fee_config exposes the source/category fee percentage plus min/max caps converted to whole USD with the response FX snapshot. percentage is a percent value (2.2 means 2.2%, not 0.022). LMN calculates pricing.breakdown.auction_fee internally from source/category KRW rules, applies KRW caps, then converts to USD.
  • pricing.market_assessment is null for dealer-source vehicles (no auction market to compare against).
  • comparables.past_sales is sold-only and empty for dealer vehicles or when no matching sold comps exist in the past 4 weeks.
  • comparables.upcoming_sales contains comparable future auction options and is empty when none exist. It does not include sold_price.
  • pricing.history contains auction appearances for the same physical car, matched internally by Korean license plate across supported auction sources. Each pricing.history[].vehicle_id is the listing ID for that auction round and may differ from the current response id. It is empty when the car has no known prior/current auction appearances with a usable listed price.
  • body_condition / inspection_report are populated for dealer-source vehicles when Encar has an inspection record; null only when the upstream inspection is missing (404). A transient failure returns 503 dealer_upstream_unavailable.
  • encar_history is present on live encar_* detail for partners with the detail_encar_history feature enabled (absent otherwise); each of its sections is null when Encar has no data for it. See Encar history and condition.
  • body_condition.image_url is returned only when LMN has a mirrored HTTPS image. Upstream auction-site image URLs are not exposed; use panels[] when image_url is null.
  • vin and license_plate may be null for pre-auction listings.
  • fuel, transmission, color may be null for rare upstream data gaps.
  • order is null unless you hold an order on this car and the response was served from that order’s snapshot; then it is { id, status, purchase_price, purchase_price_usd, buyable: false } and pricing.listing_price reflects your recorded purchase price. See Schemas → order.
Auction grade and condition-tag descriptions are published at Auction guide — Grades.

​
Encar history and condition

Live encar_* detail (GET /v1/vehicles/{id}, the live pass of GET /v1/vehicles/lookup/{key}, and order creation) carries encar_history: the history and condition information Encar shows its buyers, at no extra credit cost. Present for partners with the detail_encar_history feature enabled; contact LMN to enable it. Without it, encar_history is absent and detail is served as before.
  • All or nothing. If any of the Encar reads behind a detail (inspection, insurance record, history page, Encar Certified) fails, the response is 503 dealer_upstream_unavailable. Retry with the usual backoff. You never receive a response with some sections silently missing.
  • null means Encar has no data. A car without an open insurance record, without a history page, or never diagnosed by Encar returns 200 with that section null. usage_cautions is null when Encar’s page shows no use history at all; individual flags are never guessed as false.
  • Not present: on auction and Danawa vehicles, on lookup recall responses (listing_status sold/reserved), and on order snapshots stored before this field existed (the key is absent, not null).
  • Text: Encar’s Korean comments and the diagnosis center are returned as { "ko": "...", "en": "..." }; en is null when translation was unavailable. Amounts are whole KRW; dates are YYYY-MM-DD or YYYY-MM.
  • insurance.claims[].type_code is Encar’s raw code. type_label is set only for codes verified against Encar (3 → other_party_insurance_claim) and is null otherwise.
  • usage_cautions.theft (a caution flag on Encar’s history page) and insurance.theft_claim_count (insurance theft claims) are different facts.
  • No owner names, addresses, contact details or plates from these sources are returned.

​
Pricing

Field-level reference for the pricing object — including listing_price, sold_price, auction_fee_config, discount_config, breakdown (with symmetric auction_fee/dealer_fee integers and post-discount estimated_landed notes), history, and market_assessment — lives in the Vehicle schema: Schemas → Vehicle → pricing. All monetary values inside pricing are whole USD integers. pricing.breakdown.estimated_landed is the only field that’s already post-discount; everything else (listing_price, sold_price, the line-item costs in breakdown) is gross. To get an exact landed total for your specific bid (rather than LMN’s illustrative number against an internal basis price), use the recompute formula below.

​
Recomputing landed cost for your bid

estimated_landed is a comparison aid, not a quote. For exact bid planning, recompute using your intended bid (all amounts in USD):
ocean_freight is not a fixed constant. It is resolved per vehicle: Mercedes-Benz is 1800 for any body type; other makers are 1800 for SUV-class (SUV, minivan, van, truck) and 1500 for sedan-class (sedan, compact, wagon, coupe, convertible); an unknown body type uses 1500. Always read pricing.breakdown.ocean_freight from the response instead of hardcoding a value.
Rounding rules Caveats
  • **FX rounding (±$1).** LMN internally computes the auction fee in KRW against the KRW source-of-truth fee schedule, then converts to USD at the response edge. Partners recomputing entirely in USD may see a ≤$1 difference vs. LMN’s KRW-side math. The invoice is authoritative.
  • Planned bid vs. actual purchase price. your_bid_usd is the partner’s intended bid — typically a ceiling. At settlement, LMN recomputes auction fee and discount against the actual hammer price (purchase_price_usd on the order), which may be lower than max_bid_amount_usd. The invoice reflects what was actually won at, not the ceiling.
  • listing_price vs. internal basis. The basis used for estimated_landed is sold_price if available, otherwise LMN’s market-derived final-price estimate, otherwise the auction starting price. For unsold cars with no estimate this happens to equal listing_price, but listing_price itself does not drive the calculation in all cases.

​
Similar-sales definition

The comparables.past_sales array surfaces up to 20 comparable cars that sold in the past 4 weeks. The comparables.upcoming_sales array uses the same match rules but only includes future upcoming auction options. Sort order is by auction date descending (most recent first). past_sales never includes upcoming; future alternatives are returned only in upcoming_sales. These defaults match LMN’s internal “Market Comparison” logic shown in the web UI, so the partner API returns the same comp set an LMN operator would see for the same vehicle.

​
Market assessment (pricing.market_assessment)

A derived server-side summary so you don’t have to compute comp medians client-side. Runs on the comparables.past_sales set (sold comps only) and compares their starting-price median to your current listed/estimated price. diff_percent is the % the current listed/estimated price is below (positive) or above (negative) the comp median. price_drop, when present, reports how the same vehicle’s starting price has moved across prior auction rounds — useful in combination with the label (a good + 2-round drop is a different signal than good + first appearance).
This is an advisory signal, not a valuation guarantee. It reflects starting prices of comps in the past_sales window, not expected auction-day outcomes. Always apply your own deal logic on top.

​
Errors

Full Vehicle schema in Schemas.

​
GET /v1/vehicles/lookup/{key} — Lookup by VIN or plate

The same detail payload as GET /v1/vehicles/\{id\}, but keyed by something you already hold: a VIN from a funding application, or a license plate off a photo. Use it to answer “do you have a record of this car?” without knowing our id. This endpoint is recall, not browse. Unlike the list and detail-by-id endpoints, it returns a car whether or not it is still for sale — sold listings, cars under contract, and auction lots that already ran all resolve here. Read listing_status on every response before treating a price as a quote. If you want live inventory only, filter on listing_status == "live". Key detection is automatic. A key containing any Hangul syllable is treated as a license plate; anything else must be a 17-character VIN.
The response body is byte-for-byte the detail body — see GET /v1/vehicles/{id}. A X-LMN-Lookup-Key-Type header echoes vin or plate so you can confirm how your key was read.

​
One car, two listings

Encar publishes some cars twice — a regular listing and an 엔카믿고 listing, with adjacent ids and identical specs. Roughly 58% of live VINs and 51% of live plates match more than one id. The lookup returns the most recently seen first and transparently tries the other if the first cannot be resolved. Two lookups of the same key can therefore return different id values for the same physical car. Match on license_plate or vin, not on id, if you need to tell cars apart.

​
Freshness

Plate coverage and VIN coverage are not the same. A plate lookup that finds no indexed candidate falls through to a live Encar search (see “One car, two listings” above), so it reflects current inventory even for a car we haven’t indexed yet. A VIN lookup has no such fallback — the live-search fallback is plate-only — so a VIN only ever matches our indexed dealer snapshot, which does not cover every live listing. A VIN 404 therefore does not prove the car is unavailable; it may simply be outside what we’ve indexed. If you hold both the VIN and the plate for a car, prefer the plate. A planned alternate-identifier retry (see Photos) will narrow this gap for VINs whose plate we already hold; it is not yet released. Auction inventory is unaffected by the above. Auction lots are indexed directly from our own auction data, not proxied through a third-party search, so this asymmetry is a dealer-inventory concern only. Auction recall also reaches past lots, not just upcoming ones, so a VIN that went through an auction we covered resolves even long after the sale. Lots we withdrew or never captured an outcome for stay unreachable.

​
Photos

The lookup body carries the same photos and photo_tags as detail-by-id — see Schemas → Vehicle Detail. What you get depends on the source and on whether the record is still live: A 404 is not a photo outcome at all: it means we hold no record of the key (see Freshness for why a dealer VIN can 404 while the car is live on Encar). Today the lookup does not translate a VIN into a plate to try the plate-only live search on your behalf, so a VIN we never indexed cannot reach that car’s Encar photos; if you hold the plate, look the plate up. Planned alternate-identifier retry — not yet released. Once released, a key that matches no listing is retried once with the vehicle’s verified other identifier — VIN → plate or plate → VIN — before we answer 404. The alternate comes only from identity evidence LMN already holds: a registry VIN/plate pair stored by an earlier History lookup of that car, or an LMN listing that carried both identifiers. By default we do not buy a registry lookup on the Detail endpoint’s behalf; a separately gated paid resolution may be switched on later and will be announced in the changelog. A car reached through its alternate identifier returns the same photos and photo_tags as a direct hit. A VIN we have never indexed and never resolved through History therefore still returns 404, and that 404 will say why — details.reason in the Errors table below.

​
Availability — read listing_status

Every vehicle body carries listing_status, and on this endpoint it is the field that tells you whether what you are holding is an offer or a record: Anything other than live is a historical record. The price fields are whatever we last observed and must not be quoted as an offer. One exception has no marker. If you have already created an order for a car, the lookup returns your stored order-time snapshot before ever calling upstream — verbatim, and its listing_status reflects that snapshot, not the car’s state now. This applies only to cars you’ve ordered. Separately, and independent of the above: candidate ids are cached for 5 minutes, so a car listed in the last few minutes may return 404 briefly until the cache turns over.

​
Errors

A 503 and a 404 mean different things here. A 503 always means “ask again”. A 404 means we hold no record of the key at all — not that the car has sold, which now comes back as a sold result rather than a 404. How much a 404 tells you still depends on the key. For auction inventory and for plate lookups we search as widely as we can, including a live upstream search for plates, so a 404 there is a reasonably strong signal though not an absolute one. For a VIN against dealer inventory it is weaker: see Freshness above, since a VIN matches only our indexed snapshot.

​
Fuel categories

Source-specific fuel normalization is live in KR production as of October 20, 2026, 22:47 KST. Other environments may differ. Auctions retain the 12 canonical tokens shown above. Encar uses only diesel, diesel_electric, electric, gasoline, gasoline_electric, gasoline_lpg, lpg, other. Dealer-only Encar facets contain exactly these eight; mixed facets union them with observed auction categories. Multiple fuel values use OR semantics. Missing or blank fuel is null. Unknown auction fuel is also null, and auction other requires an explicit Other label. Every unsupported or unrecognized nonblank Encar source value becomes other. gasoline_lpg selects gasoline/LPG Bi-fuel cars, including both source spellings. A request for a category unsupported by Encar, such as cng or hydrogen, matches no Encar rows; it never turns into an other or unfiltered request. Encar other searches a bounded OR of known source labels: 기타, CNG, 가솔린+CNG, LPG+전기, and 수소, with exact category post-filtering. Arbitrary future nonblank labels normalize to other when read, but discovery through this bounded live search may be incomplete. Legacy inputs remain accepted: hybrid, gasoline_hybrid, plug_in_hybrid, and gasoline_plug_in_hybrid normalize to gasoline_electric; diesel equivalents normalize to diesel_electric; dual_fuel_lpg to gasoline_lpg; and lpi_hybrid/lpg_plug_in_hybrid to lpg_electric. These aliases are not returned as output. HEV and PHEV are not distinguished by the source fuel category. When following a dealer-inclusive next_cursor, keep every query parameter—including limit—unchanged. To change the page size, start a new search without the cursor.