Server-to-server organization access
Connect approved systems through OLT API access
Use an organization-bound API key from a trusted server to read operational data and submit the supported changes listed below. The enabled OLT API v1 surface depends on the organization's modules; shipments are read-only, while invoice creation produces a draft that is sent from the ERP.
API key prerequisites and boundaries
Plan the key owner, secret storage, request rate, monitoring, and retirement before an integration sends its first request.
An organization administrator creates the key
An active organization owner or administrator creates and manages API keys in ERP Settings → API Keys.
The full secret is displayed once
The full Bearer key is returned only at creation. Copy it directly into a trusted server-side secret store; never place it in browser code or a public repository.
Every key is organization-bound
The key supplies one organization context and covers that organization's enabled API v1 surface. It does not carry endpoint-by-endpoint grants.
Request and key-count limits apply
Each key has a per-minute request limit from 1 to 1,000, with 60 as the creation default. An organization can keep up to ten unrevoked keys.
Expiry, revocation, and usage controls stay available
Optional expiry and revocation stop future requests, while usage records retain endpoint, method, status, response time, and last-used activity without retaining the Bearer secret.
Supported read and write workflows
These claims follow the resource families mounted under /api/v1. Exact fields, validation, pagination, and responses remain endpoint-specific.
Read workflows
Retrieve supported organization records
Organization profile
Read the API key's organization profile exposed by GET /api/v1/me.
/api/v1/me
Catalog, stock, pricing, and checkout choices
Read products, stock by SKU, product prices, categories, shipping methods, and payment methods.
/api/v1/products
/api/v1/stock
/api/v1/prices
/api/v1/categories
/api/v1/shipping-methods
/api/v1/payment-methods
Customers, orders, invoices, and shipments
Read customers, orders, invoices, and shipments. Shipment routes support list and detail reads only; invoice creation is a separate draft-only workflow.
/api/v1/customers
/api/v1/orders
/api/v1/invoices
/api/v1/shipments
Webhooks, warehouse operations, and tax
Read webhook registrations and events, mounted WMS instructions and records, tax rates, and calculated tax results.
/api/v1/webhooks
/api/v1/wms
/api/v1/tax-rates
/api/v1/tax
CMS delivery and Tradesmen availability
Read CMS pages and redirect data plus Tradesmen intake fields, availability, and appointment slots.
/api/v1/pages
/api/v1/redirects.json
/api/v1/tradesmen/intake-fields
/api/v1/tradesmen/availability
Write workflows
Submit supported operational changes
Customer records
Create customers and update supported customer fields.
/api/v1/customers
Orders
Create orders and request cancellation through the mounted order routes.
/api/v1/orders
/api/v1/orders/:id/cancel
Draft invoices
Create a draft invoice for an existing organization customer. The API does not send the invoice.
/api/v1/invoices
Webhook delivery
Register, update, and remove webhooks, and retry a recorded webhook delivery.
/api/v1/webhooks
Warehouse execution
Record mounted WMS pick, exception, progress, package, cycle-count, replenishment, putaway, and outbound LPN events.
/api/v1/wms
Tradesmen job intake
Submit an external Tradesmen service-job request.
/api/v1/tradesmen/jobs
Portfolio outreach evidence intake
Record a prospect and its consent, source, evidence, and relevance for an organization-owned portfolio outreach campaign. This API route cannot create a campaign, draft or approve copy, activate a brand, or send a message.
/api/v1/portfolio-outreach/prospects
Authenticated OpenAPI reference
WMS operation families in the authenticated contract
After creating a key, retrieve /api/v1/wms/openapi.json with the Bearer credential for exact WMS methods, schemas, pagination, idempotency requirements, and responses.
Warehouse execution
List execution events and pick instructions, then record pick confirmations, exceptions, controller progress, and package measurements.
Dock appointments
List changed dock appointments for organization-scoped warehouse coordination.
Cycle counts
List ABC-due count instructions and record guarded cycle-count results.
Replenishment
List pick-face replenishment recommendations and confirm replenishment movements.
Putaway
List pending putaway recommendations and confirm receipt-line putaway.
Stock positions
List warehouse stock positions through the organization-scoped WMS contract.
Outbound LPNs
List closed outbound license plate numbers and acknowledge induction or divert events.
X12 warehouse documents
Preview X12 943 transfer advice and preview or download X12 944 receipt advice.
Inbound receipts
List inbound receipts and retrieve one receipt by its organization-scoped identifier.
X12 943 and 944 endpoint details
Compare the implemented source-record and validation boundaries before building either warehouse document workflow.
Preview only
X12 943 transfer advice
Review a warehouse transfer advice before partner delivery
Use an organization API key to turn one eligible OLT transfer draft into a reviewable X12 004010 943 document for a warehouse-to-warehouse stock movement.
Endpoint and method
POST /api/v1/wms/edi/x12/943/preview
Send the transfer draft identifier and X12 partner and control identifiers in the request body; the response returns a private, no-store document preview.
Source-record prerequisites
- Eligible transfer draft. The transfer must be a draft owned by the API key organization, with active, distinct source and destination warehouses and, when assigned, an active 3PL client.
- Resolved product lines. The draft must contain 1 to 100 lines whose active products match the transfer organization and client ownership.
Validation boundaries
- Partner and control identifiers. Sender and receiver IDs must contain 2 to 15 supported characters, the interchange control number exactly 9 digits, the group control number 1 to 9 digits, and the transaction control number 4 to 9 letters or numbers.
- Transfer values. The requested ship date must be a valid YYYY-MM-DD date; each line needs an exportable SKU and X12 unit, a positive whole-number quantity of at most 10 digits, and the total cannot exceed 9,999,999,999 units.
Preview boundary
The POST route returns preview data, including the document and filename, in JSON only to the authenticated caller. It provides no attachment download, does not transmit to a trading partner, and neither creates, imports, nor advances a transfer.
Preview or download
X12 944 receipt advice
Review received and damaged quantities for a depositor
Use an organization API key to preview readiness and, when ready, download an X12 004010 944 document for one completed 3PL receipt.
Endpoints and methods
GET /api/v1/wms/receipts/:id/x12-944
Preview the completed receipt advice, its readiness blockers, accepted and damaged totals, and the document when every boundary passes.
GET /api/v1/wms/receipts/:id/x12-944/download
Download the ready advice as an EDI attachment only after every reported blocker is resolved.
Source-record prerequisites
- Completed 3PL receipt. The receipt must be completed, owned by the API key organization, and assigned to an active 3PL client; an optional clientId can only narrow that organization-scoped selection.
- Receipt and product evidence. The receipt needs an exportable warehouse, receipt number, received date, and 1 to 1,000 lines with product SKUs, units, and accepted and damaged quantities.
Validation boundaries
- Request and partner identifiers. The receipt ID and optional clientId must be positive PostgreSQL integers; supplied query values must be single strings, and sender, receiver, and envelope controls use the same bounded X12 identifier rules as the 943 preview.
- Readiness blockers. Preview reports blockers for missing or unsupported facility, depositor, receipt, SKU, unit, quantity, lot, date, line-count, and control data; damaged quantity cannot exceed received quantity.
Preview and download boundary
Both GET routes are read-only and return preview or attachment data only to the authenticated caller. An unready preview reports blockers without a document, and download returns 422 until ready; neither route creates, imports, or updates a receipt or transmits the advice to a trading partner.
Availability and implementation limits
Shipments are read-only; invoices are draft-only through the API
The mounted shipment router exposes GET list and detail handlers only. Invoice creation produces a draft, while sending remains inside the ERP.
Module availability can vary
A mounted route does not guarantee that every organization has its backing OLT module or records enabled.
The API is not the full ERP interface
Organization-wide key scope covers the enabled v1 surface; it does not make unmounted ERP actions available.
The WMS contract remains authenticated
After key creation, GET /api/v1/wms/openapi.json with the Bearer key for the current machine-readable WMS contract. It is not served anonymously.
From account access to a controlled integration
Keep credential ownership and the enabled route contract explicit throughout setup.
-
Confirm organization access
Register an OLT account or use an existing active organization owner or administrator account.
-
Create the server credential
Open ERP Settings → API Keys, name the integration, choose its per-minute request limit, and create the key.
-
Store the one-time secret
Copy the key into the integration server's secret store before leaving the creation result.
-
Implement only supported routes
Use the Bearer key from server-side code and build only against the mounted v1 routes and their endpoint contracts.
-
Monitor and retire
Review usage and last-used activity, then revoke the key when the integration is retired or the secret may be exposed.
API access questions
What can an OLT API key read and write?
Mounted v1 routes read organization, catalog, stock, pricing, customer, order, invoice, shipment, webhook, WMS, tax, CMS delivery, checkout, and Tradesmen records. Writes are limited to mounted customer, order, draft invoice, webhook, WMS, Tradesmen job, and portfolio outreach evidence-intake workflows; outreach drafting, approval, brand activation, and sending stay outside the public API, shipments are read-only, and invoice sending stays in the ERP.
Who can create an API key, and where should it be stored?
An active organization owner or administrator creates the key. Its full secret is displayed once and should be copied directly into a trusted server-side secret store.
Can a key be limited to individual endpoints?
No. A key is bound to one organization and covers that organization's enabled API v1 surface rather than endpoint-by-endpoint grants. Per-minute request limits, optional expiry, and revocation still apply.
Is every API workflow available to every organization?
No. Module availability and records can vary by organization, and the public API exposes only its mounted v1 routes rather than every action in the ERP interface.
Choose the next step for your organization
Existing administrators can manage keys now. New clients can contact OLT to discuss their integration requirements.