JobBOSS² API: What It Covers and How to Integrate

Yes. JobBOSS² has a public REST API with an OpenAPI spec on ECI's integrations site, but ECI says it is "currently only supported for JobBOSS² hosted (Cloud) customers" and must be activated by ECI. Classic JobBOSS has no published API. On-premise shops integrate through SQL Server reads, exports, and ECI or partner connectors.

If you run hosted JobBOSS², you get documented OAuth, filtering, paging, and write endpoints for quotes, orders and time tickets. If you run JobBOSS² or classic JobBOSS on your own server, ECI documents nothing for you, and the integration has to work around an application that applies its own business rules on every save. We cover both cases below, along with the gaps ECI leaves undocumented.

Which JobBOSS are you running?

Check this first, because the two products integrate differently. JobBOSS² is ECI's current product and can be hosted or on-premise. Classic JobBOSS is the older on-premise product on Microsoft SQL Server, and it has no REST API that ECI documents publicly.

ECI launched JobBOSS² as its "go-forward cloud-based ERP" for job shops, built from two existing products, JobBOSS and E2 SHOP. The FAQ on the JobBOSS² product page lists three US deployment models: a multi-tenant SaaS cloud, a private hosted cloud, and a traditional on-premise installation. Many shops still run the older products. A May 2026 CMMC white paper by David Koran notes that classic JobBOSS Professional and Enterprise run on Microsoft SQL Server, larger E2 installs run on SQL Server, and smaller E2 installs use a Microsoft Access file, with Windows desktop clients connecting straight to the database.

Partners treat the two products as separate integrations. MachineMetrics' JobBOSS² guide uses ECI's REST API, while its classic JobBOSS guide connects directly to the SQL Server database on port 1433. That classic guide is also one of the few public places that names real tables: it reads Job, Job_Operation, Work_Center and Employee, and writes labor to Job_Operation_Time, Transaction_Data and Transaction_Detail. Those names describe classic JobBOSS only. If you are on classic, skip to the on-premise sections.

What does the JobBOSS² API actually cover?

As of October 2026, the published JobBOSS² API has 119 paths covering customers, quotes, estimates, orders, routings, time tickets, purchasing, AR invoices and quality records. That is 102 GET, 24 POST and 18 PATCH operations, with no DELETE operations and no webhooks.

ECI's docs page is a Swagger UI, and the spec behind it is public at api-jb2.integrations.ecimanufacturing.com/openapi.json, titled "JobBOSS² Public API," version v1. Read it before you call ECI. You can see whether the objects you need exist before anyone quotes you an integration. Grouped by the work a shop usually wants automated, the spec exposes:

• Sales: customers, contacts and shipping addresses can be created and updated. Quotes and quote line items support create and update. Orders, order line items, order routings and releases support create, and most support PATCH.
• Engineering: /estimates, which holds part records keyed by part number, supports create and update, with read access to estimate materials and routings. Operation codes and product codes are read only; work centers can be created.
• Shop floor: time tickets and time ticket details support GET, POST and PATCH, as do attendance tickets. /issuing-materials/stock-to-job-transfer issues stock to a job.
• Purchasing and finance: purchase orders and PO line items (read and PATCH), vendors, AR invoices, AP checks, GL codes, terms and tax codes.
• Quality: non-conformances, corrective and preventive actions, document control and tooling maintenance, all read only.
• Reports: POST /api/v1/reports starts a report and GET /api/v1/reports/{requestId} retrieves it.

All dates go in and come out in UTC. GET requests return a default field set, and you ask for others with fields=a,b,c. Filters use field[operator]=value with eq, ne, gt, gte, lt, lte, in, notin and null. Paging uses take and skip, with a default page size of 200, and list responses come wrapped in a Data array. Most resources carry lastModDate and uniqueID, which are what incremental sync is built on.

Some write rules are easy to miss. Creating an order without an order number only works if auto-numbering is turned on in company maintenance. Quote prices come in two currencies (price1 and price1Foreign), and you may send only one; the API calculates the other from the exchange rate. New estimates pick up default quantity breaks only when useDefaultQuantities is true. The spec also warns that filtering revisedDate for null returns a 500 error.

Who can use the JobBOSS² API, and how do you get access?

Officially, hosted JobBOSS² customers, once ECI activates it. You request activation through your ECI account manager or support, then create an API user in ECI's Integration Engine management console, which issues a client ID and secret for OAuth 2.0 client credentials.

The Authentication API spec fills in the mechanics. Tokens come from POST /oauth2/api-user/token with grant_type=client_credentials and scope=openid. Each token lasts 60 minutes, there is no refresh token, and the token endpoint allows 100 requests per minute per source IP. ECI recommends caching the token, fetching a new one near expiry or on a 401, and stopping after about three retries. MachineMetrics adds that the client secret is usually shown only once.

On-premise JobBOSS² is less clear than ECI's one-line statement suggests. MachineMetrics' ERP troubleshooting FAQ lists its JobBOSS² REST connector as working on-premise, and says "there is an API bug in on-prem versions that requires using a SQL route for certain operations." ECI also publishes a product-agnostic ERP API (v2.1) that lists JobBOSS² and says the database behind an API user "could be a cloud hosted ERP or on premises install" depending on the product. If you are on-premise, ask your account manager in writing whether either API is available and supported for your install.

Here is a minimal incremental pull for hosted customers. Offset paging over records that are changing can skip a row edited mid-run, so start each run a few minutes before the previous high-water mark, dedupe on uniqueID, and run a full reconciliation nightly. Test the lastModDate filter on your tenant, because the spec documents filter syntax generally and does not list filterable fields per resource.

import requests

TOKEN_URL = "https://api-user.integrations.ecimanufacturing.com/oauth2/api-user/token"
API = "https://api-jb2.integrations.ecimanufacturing.com/api/v1"

def get_token(client_id, client_secret):
    r = requests.post(TOKEN_URL,
        auth=(client_id, client_secret),          # HTTP Basic is accepted
        data={"grant_type": "client_credentials", "scope": "openid"},
        timeout=30)
    r.raise_for_status()
    return r.json()["access_token"]               # 60 minutes, no refresh token

def changed_orders(token, since_utc, take=200):
    skip, seen = 0, set()
    while True:
        r = requests.get(f"{API}/orders",
            headers={"Authorization": f"Bearer {token}"},
            params={"lastModDate[gte]": since_utc.strftime("%Y-%m-%dT%H:%M:%SZ"),
                    "sort": "+lastModDate", "take": take, "skip": skip},
            timeout=60)
        if r.status_code == 401:
            raise PermissionError("token expired: fetch a new one and resume")
        r.raise_for_status()
        rows = r.json().get("Data") or []         # list responses are wrapped in Data
        for row in rows:
            if row["uniqueID"] not in seen:
                seen.add(row["uniqueID"])
                yield row
        if len(rows) < take:
            break
        skip += take

Writes look like this. The spec requires employeeCode, jobNumber and ticketDate for a time ticket detail; the other fields shown are optional. The spec describes no idempotency key, so if a POST times out, query /time-ticket-details for that job, employee and date before you retry, or you may book the labor twice.

POST /api/v1/time-ticket-details
Authorization: Bearer <token>
Content-Type: application/json

{
  "employeeCode": 1042,
  "jobNumber": "24-0318",
  "ticketDate": "2026-10-26",
  "stepNumber": 20,
  "piecesFinished": 48,
  "piecesScrapped": 2
}

What does ECI not document about the JobBOSS² API?

ECI publishes no schema, no webhooks, no DELETE operations, no sandbox details and no rate limits for the data API itself. Plan for polling, status-based cancellations and modest request rates.

We could not find any of the following in ECI's public material in October 2026:

• Clear support terms for on-premise JobBOSS², given the partner evidence above.
• A data dictionary or schema for the JobBOSS² database, or a statement on whether ECI ships read-only reporting views.
• Webhooks. Changes in JobBOSS² reach other systems only when something polls for them. MachineMetrics says the REST API "does not provide the real-time labor ticket webhook events" its ERP-driven mode needs, and ECI's Amper announcement says Amper pulls ERP data every 15 minutes.
• Rate limits on api-jb2. The auth spec publishes its own limit and adds that "other more specific rate limits may also apply."
• A sandbox or test company for development, and pricing for API activation.

In practice, a customer-facing order status lags JobBOSS² by your poll interval, so tell your front office what that interval is. Because nothing can be deleted through the API, cancellations have to be status changes you make with PATCH, and your sync must treat a status change as the end of a record. For pacing, MachineMetrics' connector defaults are a reasonable reference: a 5-minute poll interval, 20 records per page and 3 retries.

How on-premise JobBOSS shops integrate today

On-premise shops, on JobBOSS² or classic JobBOSS, have four options: ECI's packaged integrations, flat-file exports and imports, the built-in report designer, and reading the SQL Server database directly. Use them in roughly that order.

The JobBOSS² integrations page lists ECI MES, Payments and Commerce Suite, KnowledgeSync, QuickBooks, uniPoint, Paperless Parts and CADLink. The features page says some integrations "are through API, and some are via flat file," and that ECI's custom development team will build apps and reports when no built-in integration exists. Neither page separates these by deployment, so confirm on-premise support for each one with ECI.

After that comes the database. ECI publishes no system requirements or schema for on-premise JobBOSS², so check what your server actually runs. Consultants such as Linked Operations describe building Crystal Reports and SSRS reports directly against the JobBOSS SQL database, and note that JobBOSS² itself uses the Stimulsoft report designer. Reading that database is how most custom JobBOSS dashboards get built.

Outside the few tables partners have published, the joins and status codes are undocumented, so you learn them the way you learn any vendor schema. Trace what the application writes when a user performs a known action, compare row counts against screens and reports, and write down every assumption. That is the enumerate, probe, validate, abstract method we used on an undocumented SOAP CRM API for an ISP, where schema validation later caught three vendor-side changes before they broke anything. The broader approach is in our guide to legacy system integration with reverse engineering and AI.

Check your ECI license agreement before you connect anything to the database, because ECI does not publish a policy on direct database access. This is not legal advice; review your license agreement and MSA with counsel. Our post on whether it is legal to reverse engineer software covers the general US picture.

Why you should not write your own SQL into the JobBOSS database

Read from the database if you need to, but keep your own writes out of it. JobBOSS applies business rules when a user saves a record, and a hand-written INSERT or UPDATE can skip them, leaving data that looks right on screen and costs out wrong.

The API spec shows some of those rules. Order numbers depend on a company maintenance setting, quote prices are converted between currencies on write, and estimates pick up default quantity breaks only when asked. Some logic may also live in the database as triggers or constraints, but nothing public tells you which rules live where, so you cannot know what a raw write bypasses.

Partner connectors are a different case. MachineMetrics' classic connector writes labor with scoped INSERT and UPDATE grants on specific tables, after its own testing and with its own support behind it. Your ad hoc SQL has neither. The other risks:

• An upgrade can change the schema, and ECI has never published it as a contract, so nobody owes you notice.
• A long-running integration query can hold locks that stall the desktop clients on the shop floor.
• SQL Server Audit can record which database login made a change, but JobBOSS's own history will not show an operator. If you hold CUI under CMMC, NIST SP 800-171 Rev. 2 requirement 3.3.2 expects actions to be traceable to individual users.
• When numbers go wrong, ECI support will reasonably ask what else touched the data. Check your support terms.

A safe JobBOSS integration pattern: read replica plus your own API

Copy the data to a server you control and put a small API in front of that copy. Every write still goes through a path ECI or a partner supports, so other systems get a stable contract and JobBOSS stays the only thing writing its records.

1. Make a read copy. On SQL Server Standard edition, basic availability groups do not allow reads on the secondary. The usual Standard options are a nightly restore of the backup you already take, or log shipping to a secondary in STANDBY mode, readable between restore jobs. Enterprise edition supports readable secondary replicas, but Microsoft notes that each instance hosting a readable replica needs a SQL Server license. Hosted customers skip this step and pull through the API into their own database.
2. Map the schema on the copy. Document every table and column you depend on, with the screen or report that proves its meaning, and keep the file in version control.
3. Expose business objects such as "open jobs with next operation" or "order status for customer X," not raw tables. When ECI changes a column, you fix one mapping instead of every consumer.
4. Validate on every sync. Check column types, row counts and a few known records, and stop the sync with an alert when a check fails.
5. Route writes through the JobBOSS² API for hosted customers, an ECI or partner connector, a documented import, or a work queue that a person approves in the JobBOSS client.

Which integration approach fits each JobBOSS² need?

Use a packaged connector when one exists and fits your process, the JobBOSS² API when you are hosted, and a read copy plus queued writes when you are on-premise. The table covers the integrations job shops ask about most.

Machine monitoring needs its own design, because PLC and sensor data have to land somewhere before they mean anything in the ERP. Our post on MES integration between the ERP and the PLCs in older plants covers that layer.

JobBOSS alternatives: own the integration or swap the ERP?

If your complaint is integration and JobBOSS still runs job costing and scheduling well, price an integration layer before you price a new ERP. Replace the ERP when the core workflow no longer fits the shop. An API alone rarely justifies a migration.

ECI says its own JobBOSS² implementations average a few months, and any ERP change means moving part masters and routings, retraining people, and planning a cutover. A replica and a thin API layer sit next to the system your people already know. When you do change ERPs later, you rewrite the mappings in that layer while the systems that call it keep working. Moving from on-premise to hosted JobBOSS² is a third option that keeps the same ERP and gets you the documented API.

If you do evaluate other ERPs, check what this post checked for ECI: whether the API is documented publicly, which deployments it covers, and whether it can write the records you need. Our Epicor Kinetic on-premise versus cloud API guide runs that check on another common mid-market ERP, and custom manufacturing software versus off the shelf covers when a custom layer beats a replacement.

What to do first with a JobBOSS integration project

Write down which product and deployment you run, then list the three integrations that cost you the most re-keying each week. If you are hosted, download the OpenAPI spec and confirm that each object you need has the GET, POST or PATCH you expect. If you are on-premise, record your SQL Server version and edition, check whether last night's backup restores cleanly to a second server, and ask ECI in writing which APIs and connectors cover your install.

If you want a second opinion on the plan, our manufacturing software development team builds these layers, and you can reach us here.