# JobBOSS2 API: Documentation, Keys and Integration Options

> Source: https://netray.co/erp-help/jobboss2-api-documentation-and-integration-options
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

There is no single public developer portal you can sign up to for instant JobBOSS keys. Integration options are the vendor-provided API or web services where your edition includes them (which ECI grants through your licence and account), direct read access to the SQL Server database for reporting, and file or report-based exchange. Ask ECI or your reseller what API access your version includes and how keys are issued, and use read-only SQL access for analytics.

## Kind

how-to

## System

job-shop-erp

## Erp

JobBOSS2 (ECI)

## Module

Integration / API

## Query

jobboss2 api documentation

## Alternate Queries

- jobboss api
- eci jobboss api key
- jobboss 2 public api
- jobboss api documentation

## Applies To

JobBOSS (classic) and JobBOSS2. What API access exists depends on edition, hosting model (cloud or on-premises) and licence, so confirm with ECI.

## Steps

### Choose and set up an integration

**Items:**

- Write down the integration goal: push orders in, pull job status out, feed a dashboard, or let an assistant answer questions. The goal decides the method.
- Ask ECI or your reseller in writing whether your edition includes an API, what it covers (read, write, which objects), and how keys or credentials are issued and rotated.
- For read-only reporting, create a dedicated SQL Server login with SELECT permission on the needed tables or views, and nothing else.
- For writes, prefer the vendor API or supported import routes over inserting directly into tables, since the application enforces business rules the database does not.
- Build against a test copy of the system, with test data, and log every request.
- Store credentials in a secrets manager, never in scripts or spreadsheets, and give each integration its own account so you can revoke it.
- Monitor failures and rate limits, and agree who gets alerted when an integration stops.

## Sections

### The four integration patterns

**Body:**

- Vendor API or web services: the supported route for writing data, where available. It is versioned by the vendor and respects application rules.
- SQL read access: the most common route for analytics on an on-premises install. It is fast to build and powerful, but unsupported schema changes in upgrades can break queries, so use views as a stable layer.
- Reports and exports: scheduled reports to CSV or Excel for downstream tools. It is low-tech and reliable.
- Import utilities and file drops: the usual route for bulk loads such as items, customers or orders.

### Safe read-only SQL access

**Body:**

Do not give an integration the application login. Create its own with only the rights it needs, and prefer views that expose named columns. This protects both data and upgrades.

**Code:**

- CREATE LOGIN integ_readonly WITH PASSWORD = '***';
USE [YourJobBossDb];
CREATE USER integ_readonly FOR LOGIN integ_readonly;
GRANT SELECT ON SCHEMA::dbo TO integ_readonly;
- -- Or narrower: grant on a view only
GRANT SELECT ON dbo.vw_open_jobs TO integ_readonly;

### Connecting external apps or AI

**Body:**

An external app or AI assistant needs the same three things as any integration: identity, scope and logging. Give it a read-only account, restrict it to the tables it needs, and log the queries it runs. For sensitive jobs, such as defense or aerospace work with controlled drawings, keep both the model and the integration inside your network.

If you want an assistant to write back, route those actions through the vendor API or a human approval step, not through raw updates.

## Pitfalls

- Assuming a public API with self-service keys exists. Confirm with ECI.
- Using the application database login for integrations.
- Writing straight into tables, which bypasses application rules.
- Building queries on internal tables that change between versions, with no view layer.
- Hard-coding credentials in scripts.
- Testing against live data.

## Ai Angle

Netray's ERPray connects read-only to the system of record, shows the query it ran and respects roles, which fits the SQL-read pattern for on-premises JobBOSS installs. Models run on your own servers so job and customer data does not leave the building. Any write is an approved action routed through a supported route, not a database update.

## Faq

### Does JobBOSS2 have a public API?

**Answer:** Access depends on your edition and licence. Ask ECI or your reseller what API or web services are included and how credentials are issued.

### How do I get a JobBOSS API key?

**Answer:** Through ECI, either with your account team or support, if your edition supports it. There is no guarantee of self-service issuance.

### Can I just query the JobBOSS database?

**Answer:** On an on-premises install you often can, with a read-only SQL login. Use views as a stable layer and avoid writing to tables directly.

### Can an AI assistant connect to JobBOSS?

**Answer:** Yes, typically with read-only SQL access and a grounded query layer, deployed on-premises if the data is sensitive.

## Search terms

jobboss2 api documentation, jobboss api, eci jobboss api, jobboss api key, jobboss 2 api, jobboss2 public api, jobboss sql read only, jobboss integration

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json