PPA__Vehicle_Dimension_and_VIN_Decoding_API_Integration_RFI.pdf

PERSONAL PROPERTY ACTIVITY (PPA)

REQUEST FOR INFORMATION (RFI)

VEHICLE DIMENSION AND VEHICLE IDENTIFICATION (VIN)

DECODING APPLICATION PROGRAMMING INTERFACE (API)

INTEGRATION FOR DEPARTMENT OF WAR (DoW)

PERSONAL PROPERTY SYSTEM

I. INTRODUCTION

The Personal Property Activity (PPA) is conducting market research to identify commercial sources capable of providing a high-fidelity, high-performance vehicle dimension and vehicle identification number (VIN) decoding application programming interface (API) to assist the personal property system. The government system this API will be integrating with is a modernized, cloud-based platform designed to streamline the relocation and transport of household (HHG) and privately-owned vehicles (POV) for active-duty military service members, dependents, Department of War (DoW) Civilians, and other customers supported by the DoW.

Accordingly, the PPA invites industry partners, software vendors, and data providers to submit detailed information regarding their API capabilities, licensing costs, performance Service Level Agreements (SLA), data accuracy, data caching terms, and security compliance.

This Request for Information (RFI) enables industry stakeholders to provide direct feedback on how their existing technical solutions can meet the government system’s stringent operational requirements, helping to shape future technical specifications and acquisition strategies. This RFI is issued solely for informational and planning purposes and does not constitute a solicitation for proposals.

Responses to this notice are not offers and cannot form a binding contract. The PPA is under no obligation to pursue any acquisition alternative based on this RFI, and the Government will not compensate respondents for any information received. All submissions will be kept confidential, will become the property of the U.S. Government, and will not be returned.

II. BACKGROUND

To plan, coordinate, and carry out vehicle transport logistics successfully, the government system must accurately determine a vehicle's physical footprint. Sizing errors can lead to delays and unforeseen excess costs for active-duty military service members, dependents, DoW civilians, and other customers supported by the DoW. The government system requires an automated data lookup pipeline that translates a user-entered 17-character VIN (or year/make/model/trim parameters) into a precise dimension and weight.

A. Technical and Performance Requirements

To successfully integrate with the government system, the proposed API solution must meet the following performance metrics:

1. Protocol and Format: Standard RESTful API utilizing JSON payloads, compliant with OpenAPI specifications.

2. Latency: Sub-second response times, specifically demanding less than 1,500ms p95 latency under operational loads.

3. Throughput and Scalability: Ability to support a minimum of 50 Requests Per Second (RPS) to handle seasonal peak moving volumes.

4. Uptime SLA: High-availability service offering at least 99.9% system uptime, with automated status monitoring and failover protocols.

5. Client-Side Caching: The vendor must permit local storage and caching of retrieved vehicle specifications for a specified duration to reduce redundant API hits and ensure application performance.

B. Operational and Data Requirements

The government system requires high-level data accuracy to eliminate standard automotive “blind spots” that impact logistics:

1. Data Coverage: Comprehensive coverage of all passenger vehicles, light trucks, and sport utility vehicles (SUVs) sold or registered in the United States from model year 1981 to the present, updated at least annually.

2. Trim-Level Specificity: Ability to distinguish physical variations within the same model blueprint. This includes:

a. Dual Rear Wheel (Dually) Configurations: Capturing the expanded rear axle width (~96 inches verse ~81 inches) of heavy-duty trucks.

b. Van Roof Variants: Identifying high-roof, standard, or extended-length cargo van profiles (e.g., Ford Transit variants) to prevent clearance issues.

c. Overhang and Clearance: Providing front and rear overhang measurements and minimum ground clearance to calculate ramp approach angles.

d. Mirrors Folded versus Unfolded: Access to true overall width measurements to assess fit inside enclosed transport carriers.

3. Units of Measure: Seamless support for both U.S. Customary units (whole inch to quarter of an inch, pounds) and Metric units (millimeters, kilograms).

4. Foreign Vehicle: Support for non-U.S./international VIN strings or non-checksum vehicle identifiers (e.g., JDM frame numbers or European ISO 3779 formats).

C. Security and Compliance Requirements

Because the API will process transaction data associated with active-duty military service members, dependents, DoW civilians, and other customers supported by the DoW movements, it must adhere to strict defense security baselines:

1. Data Security: Must maintain SOC 2 Type II certification to verify the vendor's data protection, confidentiality, and operational integrity.

2. TLS Support: Capability to secure communications using Transport Layer Security (TLS) 1.3 or higher encryption for all data in transit.

III. INFORMATION REQUESTED

Vehicle data providers, API platforms, and interested industry partners are requested to submit a response covering the following areas:

A. General Company Information

1. Company Name and Address:

2. Point of Contact (POC) Name / Telephone / Email:

3. Unique Entity Identification (UEI):

4. Mission & Capability Statement: (Brief overview of your organization's core focus and commercial experience in the automotive data space).

5. GSA Schedule Availability and Government Contracts: Please identify if you have API solutions that are currently listed under a GSA Schedule (e.g., Category F: Information Technology, MAS Schedule), including your contract number and applicable Special Item Numbers (SINs). You may also provide information on any current or previous Government contracts within the last five years for Vehicle Dimension and VIN Decoding API type or related work.

B. Technical and Operational Feedback

Please respond to the following questions detailing how your API platform matches the government system requirements:

1. Cost and Workload:

a. What are the standard pricing and licensing models for your API (e.g., flat monthly subscription, tiered volume brackets, pay-as-you-go metered pricing, or custom enterprise SLAs)?

b. Are there one-time integration or setup fees?

c. Does your licensing terms permit client-side caching of vehicle dimensions to optimize performance, and if so, under what conditions?

2. Timeline:

a. What is the typical technical onboarding timeline for developers to integrate your API, configure keys, and begin testing?

b. What sandbox, staging, or mock environments do you provide to accelerate integration testing?

3. Standards and Data Quality:

a. How does your platform compile its vehicle dimension data (e.g., original equipment manufacturer (OEM) build sheets, algorithmic estimations, inventory scrapes, or federal filings)?

b. Explain how your API handles the "Dually" rear-wheel width discrepancy and cargo van roof-height variations. Does your API resolve these dynamically from a standard 17-digit VIN input, or does it require multi-match trim selection input from the user?

c. Detail your platform's ability to support non-U.S./international VIN strings or non-checksum vehicle identifiers (e.g., JDM frame numbers or European ISO 3779 formats).

d. Handling of Modified Vehicles: How does your API service identify or flag vehicles with non-standard OEM specifications or aftermarket modifications (e.g., raised suspensions, oversized tires, body alterations)?

Please describe if your system provides baseline OEM physical dimensions (height, width, length, clearance) that can be programmatically compared against physical measurements taken at the time of turning in a vehicle for shipment.

4. Testing and Risk:

a. What are your recommendations for setting up a robust, high-throughput integration testing pipeline with the government personal property system?

b. What fallback mechanisms or default value returns does your platform utilize when a VIN fails to resolve or when a user inputs error-ridden data?

c. How does your platform guarantee a p95 latency under 1.5 seconds during peak concurrent traffic?

5. Feedback:

a. What other technical constraints, data endpoints, or operational practices should PPA consider for successful integration?

IV. RFI SUBMISSION INFORMATION & GOVERNMENT RESPONSE

Please submit any clarifying question regarding this RFI by 4:00 PM CT, 3 September 2026. Questions and government responses will be posted under this notice.

RFI submissions are limited to one per company with no more than 15 total 8.5” x 11” pages (12 point font, Times New Roman with one-inch margins).

All RFI submissions shall only include responses to the questions asked in Section III of this RFI.

You must clearly mark and segregate any proprietary data in your submission.

RFI submissions will not be accepted after 4:00 PM (CT), 17 September 2026.

RFI submissions shall only be submitted via email to all points of contact:

o Contracting Officer: Chris Frost; christopher.t.frost4.civ@mail.mil o Contracts Manager: Kevin Peaslee; kevin.p.peaslee.mil@mail.mil o Technical Lead: Chris Doyon; christopher.e.doyon.civ@mail.mil

The Government is not seeking generic company brochures or marketing materials.

The PPA may meet with all, some, or none of vehicle data providers, API platforms, and interested industry partners to this RFI.

A meeting or response to this RFI, or lack thereof does not constitute any obligation on the Government to pursue a follow-on effort, in part or whole, with specific vendors or otherwise.