@lolablankets/veracore-api

TypeScript client for VeraCore's REST API and classic SOAP web services.

The package wraps both APIs behind a single import. The REST surface is generated from an OpenAPI spec; the SOAP surface is generated from a hand-curated manifest of the operations we use (AddOrder, CancelOrder, UpdateOtherOrderInfo, GetOrderInfo, GetShippingOrder, etc).

Why this exists

VeraCore does not publish API documentation. There's no developer portal, no public OpenAPI spec, no SDK, no anything. The only reference material is buried in their support knowledge base at advantive.my.site.com, which is gated behind a login, slow to search, and inconsistent in how endpoints are described (article-per-endpoint, sometimes with sample XML, sometimes not, sometimes contradicting itself between articles).

So we built our own pipeline:

1. scripts/scrape-veracore.js logs into the support portal with Playwright, crawls the developer-corner article tree, and dumps every relevant page into veracore-docs/articles/ as markdown plus a JSON index.

2. We feed those scraped articles to AI assistants and use targeted scripts to assemble openapi.yaml (REST) and soap-manifest.json (SOAP) — a normal, machine-readable API spec describing the actual endpoints, params, and response shapes.

3. npm run generate turns those specs into the typed clients under src/generated/. The hand-written wrappers in src/client.ts and src/soap.ts add auth, env management, and ergonomics on top.

4. Postman collections under postman/ mirror the spec for ad-hoc exploration and back the smoke-test runner in scripts/smoke-test.js.

The veracore-docs/ folder stays in the repo as the canonical local copy of their docs — both because the portal is painful to use, and because having the articles offline lets agents (and humans) ground answers in the source material without re-scraping every time.

Install

npm install @lolablankets/veracore-api

Requires Node 18+.

REST usage

import { createVeracoreClient } from "@lolablankets/veracore-api";

const vc = createVeracoreClient({
  baseUrl: "https://<your-system>.veracore.com/VeraCore/Public.Api",
  username: process.env.VERACORE_USER,
  password: process.env.VERACORE_PASSWORD,
  systemId: process.env.VERACORE_OMS_ID,
});

await vc.login();

const { data, error } = await vc.raw.GET("/api/Inventory", {
  params: { query: { systemId: process.env.VC_OMS_ID } },
});

The bearer token is held in the client; subsequent calls attach it automatically. Tokens live for 3 months — call vc.checkToken() to verify, or persist the token via getToken / setToken and reuse across runs.

SOAP usage

import { createSoapClient } from "@lolablankets/veracore-api";

const soap = createSoapClient({
  baseUrl: "https://<your-system>.veracore.com",
  username: process.env.VERACORE_USER,
  password: process.env.VERACORE_PASSWORD,
});

const result = await soap.AddOrder({
  order: {
    Header: { ID: "ORD-12345", ReferenceNumber: "EDI" },
    OrderedBy: { /* ... */ },
    ShipTo: { OrderShipTo: { /* ... */ } },
    Offers: { OfferOrdered: [{ /* ... */ }] },
  },
});

Every SOAP operation in soap-manifest.json is exposed as a typed method. The client transparently switches between XML SOAP and the JSON Order Adjustment endpoints depending on the operation.

Configuration

The library itself takes credentials as constructor args — it does not read env vars. Scripts under scripts/ do read env vars; see .env.example for the full list. The main ones:

VERACORE_BASE_URL  https://<your-system>.veracore.com
VERACORE_USER      API user
VERACORE_PASSWORD  API password
VERACORE_OMS_ID    OMS system id
VERACORE_WMS_ID    WMS system id (optional)

The Postman environment under postman/veracore.postman_environment.json mirrors these for ad-hoc API exploration.

Credentials (1Password)

Live credentials are stored in 1Password under the Engineering_Secrets vault. Do not paste secrets into .env files committed to git, and do not hardcode them in scripts.

Per-tenant API credentials (one item per VeraCore tenant):

veracore-LOLAID     Lola main OMS
veracore-LOLAPA     LOLA PA tenant
veracore-LOLATX     LOLA TX tenant
veracore-GDSBOX     GDSBOX tenant

The CI publish workflow already uses 1Password via the load-secrets-action — see .github/workflows/publish.yml for the pattern.

Local usage: install the 1Password CLI (op), sign in, then run scripts under op run so secrets are injected from the vault without ever being written to disk:

op run --env-file=.env -- npm run smoke

Inside .env, reference 1Password fields using op:// URIs instead of pasting values. Example:

VERACORE_USER=op://Engineering_Secrets/veracore-LOLAID/username
VERACORE_PASSWORD=op://Engineering_Secrets/veracore-LOLAID/password
VERACORE_OMS_ID=op://Engineering_Secrets/veracore-LOLAID/oms-id

Adjust the item name to target a different tenant.

Scripts

npm run generate    Regenerate REST + SOAP types from openapi.yaml and soap-manifest.json
npm run build       Generate + compile to dist/ via tsup
npm run scrape      Refresh the local copy of VeraCore's published docs (veracore-docs/)
npm run retry       Retry failed scrape jobs
npm run smoke       Run smoke tests against a live VeraCore tenant (read-only by default)
npm run smoke:dry   Smoke tests with no network calls
npm run smoke:all   Smoke tests including write endpoints (be careful with the tenant)
npm run reports     Generate report-request payloads from the Postman environment

Repo layout

src/                    Hand-written client code (REST wrapper + SOAP envelope builder)
src/generated/          Generated types and SOAP operation tables (do not edit)
scripts/                Codegen, scraping, and smoke-test tooling
openapi.yaml            REST API OpenAPI spec, converted from VeraCore's Postman collection
soap-manifest.json      Manifest of SOAP operations we expose (endpoints, params, types)
postman/                Postman collections and environment for manual API exploration
veracore-docs/          Local mirror of VeraCore support articles, scraped for reference
dist/                   Build output (published to npm)

Order tagging helper

buildTagPayload() produces the wire shape for tagging an order with a primary classification (e.g. "EDI", "Wholesale", "Vendor Compliance") and optional sub-tags (e.g. "CustomWrap"). It supports two encoding strategies, picked at call time:

• "concat" — all tags flattened into one delimited string in ReferenceNumber (e.g. "Vendor Compliance / CustomWrap"). No Veracore admin setup needed.

• "ordervars" — primary tag in ReferenceNumber, sub-tags become typed OrderVariable fields. Requires the sub-tag field names to be defined per tenant in Veracore admin (Setup > Shopping Cart Setup > Order Variables).

  import { buildTagPayload } from "@lolablankets/veracore-api";

  const payload = buildTagPayload( { classification: "Vendor Compliance", subTags: ["CustomWrap"] }, "concat", // or "ordervars" ); // → { ReferenceNumber: "Vendor Compliance / CustomWrap" }

  await soap.UpdateOtherOrderInfo({ // ... orderID, Header, Classification ... ...payload, });

The helper is a pure function (no I/O). Callers compose it with their preferred Veracore API call — typically UpdateOtherOrderInfo for tagging existing orders (the polling/augment flow) or inline in AddOrder for create-time tagging.

A smoke script exercises the round-trip end-to-end against a live tenant:

scripts/test-sdk-update.js  Apply a tag to an existing order via the SDK
                            and confirm Veracore accepted the update.

This mirrors the production code path (Good Day creates the order, our gateway tags it after) and doesn't require an orderable test offer — just an existing order ID.

Helpers for exploring a tenant's data:

scripts/check-reference.js  Read an order by ID; print its ReferenceNo
                            and other header fields.
scripts/find-offer.js       List offer IDs in the catalog (REST GetInventory).

Updating the API surface

To pick up new endpoints or changed schemas:

1. Pull the latest Postman collection from VeraCore (or run npm run scrape).
2. Edit soap-manifest.json if you need new SOAP operations.
3. Run npm run generate to regenerate src/generated/.
4. Bump the version in package.json and publish.

License

UNLICENSED. Internal use at Lola Blankets.