jbw-api — Vendor Integration API (Spring Boot / Java 17)

Module path: st-integration/jbw-api/ · deployed as prodapi_jb360dealer / devapi_jb360dealer · fronted by JB360IntegrationAPI at api-jb360.jbwarranties.com · no IaC — manual jar uploads

Documented 2026-07-17 — this module was missing from the original handover

The July 2026 analysis covered three modules (extraction, jbw-sam, jbwui) and missed this fourth one, which has been in the repo since 2026-05-20 (commit cfc5e7a, “Spring Release Changes”). As a result the AWS pages described the jb360dealer API as “repo-less” and carried a follow-up to recover its source. Both were wrong; see Analysis Process for how that happened.

Purpose

The vendor-facing integration API: a second, independent read/write interface over the same jbwst MySQL database that jbw-sam and extraction use, aimed at external vendor platforms rather than at the JB360 portal.

It is not the jbwui backend — that is jbw-sam. It is also not the JBW public API (public-api.jbwarranties.com), which is an upstream system jbw-sam calls out to; jbw-api has no outbound HTTP client to JBW at all.

What distinguishes it from jbw-sam is the tblVendor* table family — tblVendor, tblVendorApps, tblVendorInvoice, tblVendorLocationData, tblVendorTransmissionDetails — which has no counterpart in jbw-sam. Every request is attributed to a vendor and archived.

Architecture at a Glance

Stack	Spring Boot 3.5.4, Java 17, Spring Data JPA / Hibernate (MySQL), MapStruct 1.5.5, Lombok
Lambda adapter	aws-serverless-java-container-springboot3 2.0.1
Entry point	StreamLambdaHandler implements RequestStreamHandler — src/main/java/com/maktix/jb/api/StreamLambdaHandler.java:16-26
Trigger	API Gateway proxy only — no SQS, no schedule, no S3 events
Database	jbwst MySQL via RDS IAM auth token (no stored password) — config/JpaConfiguration.java:43-73
Docs	springdoc-openapi 2.8.6, Swagger UI vendored into src/main/resources/static/swagger-ui/
Deploy	mvn package → shaded jar (classifier aws) → uploaded by hand

Endpoints

All controllers are mapped @RequestMapping({ "", "/stage" }) and annotated @SecurityRequirement(name = "cognitoAuth").

Method + path	Source
GET /dealer/{dealerid}/agreements · /{invoiceid} · /{locationid} · /modified · /created	controller/AgreementController.java:45,72,88,120,136
GET /dealer/{dealerid}/jbwagreements/{jbwAgreementId} · GET /synced/agreements/{locationid} · GET /{id}	controller/AgreementController.java:104,152,167
POST / PUT / DELETE /dealer/{dealerid}/agreements[/{id}]	controller/AgreementController.java:173,181,191
GET /dealer/{dealerId}/claims[/{invoiceId}|{locationId}|/modified|/created]	controller/ClaimController.java:45,61,77,92
GET /dealer/{dealerid}/jbwclaims/{jbwClaimId} · GET /{id}	controller/ClaimController.java:123,154
POST / PUT / DELETE /dealer/{dealerid}/claims[/{id}]	controller/ClaimController.java:160,168,178
GET /dealer/{dealerid} · GET /dealer/platform/{platformName}	controller/DealerController.java:34,43
POST / PUT /dealer/{dealerid}/locations[/{id}] · GET variants by customerId / tenantId	controller/LocationController.java:54,69,85,107,135,163
POST / PUT / GET /dealer/{dealerid}/invoices[/{invoiceid}|/{id}|/{tenantId}] + bulk	controller/VendorInvoiceController.java:59,75,91,105,116,132,143,163
GET /api-docs · /swagger-ui.html — filter-exempt	application.properties:3-4; filter/VendorResolutionFilter.java:39-46

An OpenAPI spec for this same API is also served by a jbw-sam Lambda: jbw-sam/src/swaggerjson/swagger.json (28 unique paths, each mirrored with a /stage prefix). Deployed as devapi_swaggerjson — no prod counterpart exists.

Data Flow

Every request passes through VendorResolutionFilter (filter/VendorResolutionFilter.java:57-118):

1. Resolve the vendor from the API Gateway authorizer’s principalId via tblVendorApps (must be ACTIVE, not deleted) → tblVendor (must be active) — :123-135
2. Open a tblVendorTransmissionDetails row, REQUIRES_NEW, status IN_PROGRESS — service/TransmissionLoggingService.java:39-60
3. Run the controller
4. In finally: archive the request body (POST/PUT/PATCH only) and response body to S3 at transmissions/{uuid}/request.json / response.json, then mark the row SUCCESS / FAILED — TransmissionLoggingService.java:62-94

Writes: tblAgreement, tblClaims, tblSTLocationData, tblVendorInvoice / tblVendorInvoiceItem, tblVendorTransmissionDetails. No stored procedures are called — unlike jbw-sam, which drives jbw_st_dataSync.

Configuration

All via System.getenv, none defaulted:

Variable	Used by
AWS_REGION	config/AwsConfig.java:16
DATABASE_ENDPOINT · DATABASE_PORT · DATABASE_REGION	config/JpaConfiguration.java:43-45
SECRET_NAME	config/JpaConfiguration.java:79
COGNITO_SCOPES	config/OpenApiConfig.java:39
S3_BUCKET_NAME	utils/S3UploadService.java:48,95 — bucket jb360-api-file-store

Credentials come from the Lambda execution role (DefaultCredentialsProvider). The DB password is an IAM auth token, never stored — the same bright spot jbw-sam has.

Build & Deploy

cd jbw-api
./mvnw package        # → shaded jar, classifier `aws`

No deploy configuration exists in this repo

jbw-api/ contains only .mvn/, src/, pom.xml, mvnw, mvnw.cmd — no template.yaml, no samconfig.toml, no serverless.yml, no CI workflow. The jar is uploaded to Lambda by hand (consistent with the upload-jb360-jar-files bucket).

This is worse than the jbw-sam drift: that module at least has a template describing 63 of its functions. This one has nothing. The consequence is visible in production — see the handler divergence below.

Defects

Cross-tenant authorization gap (IDOR)

VendorResolutionFilter resolves the calling vendor (filter/VendorResolutionFilter.java:142), but only VendorInvoiceService ever reads it back (service/VendorInvoiceService.java:289,295-297). Every other path trusts the {dealerid} path parameter with no check that the authenticated vendor is entitled to that dealer:

• DealerService.getDealerDetailsByDealerId(dealerId) — service/DealerService.java:21-25 — any valid vendor token reads any dealer
• AgreementService scopes only on the path’s dealerId — service/AgreementService.java:112-199
• GET /{id}, PUT / DELETE /dealer/{dealerid}/agreements/{id} and the claim equivalents resolve by primary key with no dealer or vendor filter at all — AgreementService.java:201-203,228-231,248-251
• GET /dealer/platform/{platformName} returns every onboarded dealer on a platform, unscoped — DealerService.java:27-29

Not exposed unauthenticated — /dealer/{proxy+} does have the TOKEN authorizer attached (verified live 2026-07-17). But any valid vendor token reaches other vendors’ data.

RDS IAM auth token logged at INFO

config/JpaConfiguration.java:71 logs the generated RDS auth token — a live 15-minute DB credential written to CloudWatch. The DB username (:51) and URL (:49) are logged too.

Credentials & endpoints

• Commented-out hardcoded DB credentials left in source — config/JpaConfiguration.java:46-48.
• Token URL pinned to staging — config/OpenApiConfig.java:34 hardcodes auth-jb360-stage.jbwarranties.com, with the env-var version commented out at :33. Prod Swagger hands out the stage token URL. Same for the only advertised server (Jb360ApiApplication.java:18).
• context-path=/stage hardcoded (application.properties:2) — combined with controllers double-mapping {"", "/stage"}, prod requests are served under a /stage path.
• CORS wide open — allowedOrigins("*") (Jb360ApiApplication.java:35) and Access-Control-Allow-Origin: * (filter/VendorResolutionFilter.java:146).

Correctness

• The IAM token is generated once at bean creation and SimpleDriverDataSource is not pooled (config/JpaConfiguration.java:41,58-73). The token expires ~15 minutes into a warm container’s life — long-lived warm Lambdas will fail to open new connections.
• @Size applied to Integer fields — dto/AgreementEquipmentDTO.java (locationId, invoiceItemId, installedEquipmentId). @Size has no effect on Integer; Hibernate Validator throws UnexpectedTypeException if these ever validate.
• Contradictory JPA config — hbm2ddl.auto=none (JpaConfiguration.java:120) but setGenerateDdl(true) (:105); the configured jpaVendorAdapter() bean (:112) is immediately overwritten by a bare one (:115-116), discarding the MySQL dialect.
• PII in logs and S3 — full request/response/entity objects are logged at INFO throughout VendorResolutionFilter and TransmissionLoggingService; customer name, address, phone and email reach CloudWatch.
• MAX_LOG_SIZE is declared but never used (TransmissionLoggingService.java:31) — archived bodies are uncapped despite the constant implying otherwise.
• Vendor is never encoded in the S3 key despite being passed in — utils/S3UploadService.java:53-57,100-104.

Not found here (unlike jbw-sam)

• No SQL injection. Both native queries are fully parameterized via @Param (repository/DealerRepository.java:17-51); everything else is derived JPA methods or JPQL with named params. A genuine improvement over jbw-sam.
• No DLQ concern — synchronous API Gateway invocation only.

Deployed Reality

prodapi_jb360dealer is running the SAM scaffold, not this application

	prod	dev
Handler	example.Hello::handleRequest	com.maktix.jb.api.StreamLambdaHandler::handleRequest
Env vars	none	10
VPC	none	vpc-0d29d310746998b07
Timeout / memory	15 s / 512 MB	900 s / 2048 MB

With no env vars and no VPC config, the prod function cannot reach the RDS proxy and cannot be running this app — yet the prod stage of JB360IntegrationAPI routes /dealer/{proxy+} to it. Confirm with the team whether the prod vendor API is dead or serving scaffold responses. Full evidence.

Caveats / Known Issues

• No IaC at all — the single root cause of the prod/dev handler divergence above.
• No tests in the module.
• Unverified: which external vendor platforms hold tblVendorApps client IDs — tblVendor.platformName is queried (repository/DealerRepository.java:50) but no values live in the repo. Resolve with SELECT vendorName, platformName FROM jbwst.tblVendor.
• jb360-api-file-store (the PII archive) has versioning off, no lifecycle policy, and no access logging — vendor request/response payloads accumulate indefinitely. Encrypted (AES256 + BucketKey) and fully non-public. See S3 Buckets.

July 2026 Release Delta (f16313c..1ce5b3e)

7 files, +330/−15, all DTOs — a request-validation and OpenAPI-schema hardening pass. No controller, service, repository, entity, or config change.

• Bean Validation (@Size/@Digits/@NotNull) and @Schema(maxLength=…) added across AgreementEquipmentDTO, AgreementRequestDTO, ClaimRequestDTO, InvoiceItemRequest, InvoiceRequest, LocationDTO, aligning DTO constraints to column widths.
• New renewal fields — renewedAgreementId, parentProductCode, customerId on AgreementRequestDTO; claimSummary on ClaimRequestDTO; invoiceStatus, stCreatedOn, stModifiedOn, isSeaCoast, missingEquipment, isAgreementCreated, possibleJBPlan on InvoiceRequest.