HBS Systems

## 🚀 Theneo

Theneo is the quickest, simplest way to generate high-quality, interactive API docs. Just import your API collection and we'll take care of the rest.

**⚠️ Note:** All of the stated endpoints and sections are for demonstration purposes only. Theneo does not manage payments API. Get sales data, itemize payments, push orders to POS, and more.The Orders API provides a one-stop shop for integrating advanced payment functionality. You can itemize payments with custom line items or catalog objects, send orders to real Point of Sale devices to be fulfilled, and more.In addition, the Orders API allows you to look through all of a seller's previous sales and returns itemization data, customer references, and other information from POS or online transactions.

&lt;img src="https://assets.website-files.com/61f7e03934c23c1dcc9c3cd4/6306089ecc13c15fe0a7e006_Main page_2 (with visual studoi code logo) 2.svg" alt="" height="237" width="322">

### Generate API Documentation

- Build interactive API docs
- Tailor you documentation
- Create and launch quickly
- Update easily within seconds
- Built for everyone
    

# Integrations

Import your collections manually or use our integrations to automatically migrate your work from:

- Swagger
- Postman
- Github
    

[  
](https://www.theneo.io/#)

[  
](https://app.theneo.io/signup)

Overview

Authorization

NetView Architecture and Base URL's

API Organization

Locations

Retrieve all locations

🚀 Theneo is the quickest, simplest way to generate high-quality, interactive API docs. Just import your API collection and we'll take care of the rest.

⚠️ Note**:** All of the stated endpoints and sections are for demonstration purposes only. Theneo does not manage payments API. Get sales data, itemize payments, push orders to POS, and more.The Orders API provides a one-stop shop for integrating advanced payment functionality. You can itemize payments with custom line items or catalog objects, send orders to real Point of Sale devices to be fulfilled, and more.In addition, the Orders API allows you to look through all of a seller's previous sales and returns itemization data, customer references, and other information from POS or online transactions.

&lt;img src="https://assets.website-files.com/61f7e03934c23c1dcc9c3cd4/6306089ecc13c15fe0a7e006_Main page_2 (with visual studoi code logo) 2.svg" alt="" height="168" width="200">

### Generate API Documentation

- Build interactive API docs
- Tailor you documentation
- Create and launch quickly
- Update easily within seconds
- Built for everyone
    

# Integrations

Import your collections manually or use our integrations to automatically migrate your work from:

- Swagger
- Postman
- Github

Customer

Retrieve customer

Retrieve all customers

Utilizes one or more supported query filters to search the associated customer profiles with a Theneo account.  
Without an explicit query filter, SearchCustomers returns all customer profiles based on given name and family name in alphabetical order.  
Under normal working conditions, newly created or modified customer profiles become available for the search operation in significantly less than 30 seconds. Occasionally, propagation of new or updated profiles can take up to a minute or longer, particularly during network outages and events.

Search customers

Wholegoods

Retrieve wholegood

Retrieve all wholegoods

Partial wholegood search

Autocomplete search

Service

Retrieve all repair order numbers

Retrieve single repair order details

Retrieve multiple repair order details

Authentication

OAuth

Theneo Demo TechCrunch

NetView API Documentation

Sandbox

<p class="slate-p " >API Key Authentication</p><p class="slate-p slate-indent-0" style="0px">When starting to use either the bulk API&apos;s of webhook event system you will need to use an API token to authenticate yourself with the NetView servers. HBS Systems should provide you with both an API bearer token as well as a secret key used to recreate signature&apos;s provided in some of the API&apos;s (namely webhook events). </p><p class="slate-p slate-indent-0" style="0px">Your API bearer token should be sent as a header in ALL requests noted in this document in the form <code class="slate-code">Authorization: Bearer &lt;API Token&gt;</code>. Failure to do so will result in a <code class="slate-code">403</code> HTTP status being returned.</p><p class="slate-p slate-indent-0" style="0px">For OAuth support see <a href="67813b0233b3c89b3be49fe3/67813b0e12bd360b8b57ed45" target="">OAuth section here</a>.</p><p class="slate-p " ></p><p class="slate-p " ></p>

When starting to use either the bulk API's of webhook event system you will need to use an API token to authenticate yourself with the NetView servers. HBS Systems should provide you with both an API bearer token as well as a secret key used to recreate signature's provided in some of the API's (namely webhook events). 

Your API bearer token should be sent as a header in ALL requests noted in this document in the form 

<p class="slate-p slate-indent-0" style="0px">HBS Systems deploys the NetView product as a distributed server architecture. This means that in production, <em class="slate-italic">EVERY </em>organization will have its own URL which you will need to use in your requests separate from one another. Note this does not mean each physical dealership location will have a separate URL, but the organization themselves. </p><p class="slate-p slate-indent-0" style="0px">For example consider an organization ABC Org. They purchase and operate 4 physical location stores throughout the state of Texas - ABC Equipment, DEF Equipment, GHI Equipment, and JKL Equipment. In this case their base URL for all this locations could be <code class="slate-code">https://abcorg.netviewcloud.com</code> . To access the individual locations within this organization you will need to specify the “location” parameter in the request. This takes the form of <code class="slate-code">loc&lt;id&gt; </code> . So in our example you would have access to ABC Equipment as <code class="slate-code">loc1</code>, DEF Equipment as <code class="slate-code">loc2</code>, GHI Equipment as <code class="slate-code">loc3</code>, and JKL Equipment as <code class="slate-code">loc4</code>. NetView also has the notion of consolidated locations. These are locations that aggregate information from all linked locations together. These locations are not physical locations in the real world, but more of a virtual location that is used to have a higher level view as an organization. Most of the time this will be <code class="slate-code">loc0</code> if the organization is setup in the system, but it can vary depending on organization.</p><p class="slate-p slate-indent-0" style="0px">For testing a single server is provided as the sandbox URL via <code class="slate-code">https://hbsapi.netviewcloud.com</code>. This server has its own set of API keys and secrets that will be separate from your production set, so please make sure to use the correct ones.</p><p class="slate-p " ></p><p class="slate-p " ></p>

HBS Systems deploys the NetView product as a distributed server architecture. This means that in production, 

organization will have its own URL which you will need to use in your requests separate from one another. Note this does not mean each physical dealership location will have a separate URL, but the organization themselves. 

For example consider an organization ABC Org. They purchase and operate 4 physical location stores throughout the state of Texas - ABC Equipment, DEF Equipment, GHI Equipment, and JKL Equipment. In this case their base URL for all this locations could be 

 . To access the individual locations within this organization you will need to specify the “location” parameter in the request. This takes the form of 

 . So in our example you would have access to ABC Equipment as 

. NetView also has the notion of consolidated locations. These are locations that aggregate information from all linked locations together. These locations are not physical locations in the real world, but more of a virtual location that is used to have a higher level view as an organization. Most of the time this will be 

 if the organization is setup in the system, but it can vary depending on organization.

For testing a single server is provided as the sandbox URL via 

. This server has its own set of API keys and secrets that will be separate from your production set, so please make sure to use the correct ones.

<p class="slate-p " >The API&apos;s are organized into separate groups based on module within the NetView system. These are: Customers, Dealership, ECOM, Parts, Rental, Service, User, and Wholegoods. </p><p class="slate-p " ></p>

The API's are organized into separate groups based on module within the NetView system. These are: Customers, Dealership, ECOM, Parts, Rental, Service, User, and Wholegoods. 

<p class="slate-p " >The <em class="slate-italic">Locations</em> API&apos;s are interfaces to reading and interacting with locations within the NetView system. In NetView a location is an entity that is used to track company information and as a container to group data into. An entity may be a child of another, in what is referred to as a Consolidated Setup. This occurs when the <code class="slate-code">id</code> and <code class="slate-code">parent_id</code> fields differ in value. If the <code class="slate-code">id</code> and <code class="slate-code">parent_id</code> field are identical then that means the location is a standalone and is not a child of another. </p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

 API's are interfaces to reading and interacting with locations within the NetView system. In NetView a location is an entity that is used to track company information and as a container to group data into. An entity may be a child of another, in what is referred to as a Consolidated Setup. This occurs when the 

 field are identical then that means the location is a standalone and is not a child of another. 

<p class="slate-p " >The <em class="slate-italic">Customer</em> API&apos;s are interfaces to reading and interacting with customers within the NetView system. In NetView a customer is an entity that is used to track information, purchases, and account balances. A customer can be a single person, a business, or government entity.</p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

 API's are interfaces to reading and interacting with customers within the NetView system. In NetView a customer is an entity that is used to track information, purchases, and account balances. A customer can be a single person, a business, or government entity.

<p class="slate-p " >The <em class="slate-italic">Wholegoods </em>API&apos;s are interfaces to reading and interacting with pieces of equipment within the NetView system. In NetView a wholegood is an entity that is used to track information about a piece of (usually) serialized equipment. This means that the item has a serial number assigned. </p><p class="slate-p " >Wholegoods are uniquely identified by their field <code class="slate-code">stock_number</code>. This field is the NetView number used to track a piece of equipment throughout other modules as well.</p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

API's are interfaces to reading and interacting with pieces of equipment within the NetView system. In NetView a wholegood is an entity that is used to track information about a piece of (usually) serialized equipment. This means that the item has a serial number assigned. 

Wholegoods are uniquely identified by their field 

. This field is the NetView number used to track a piece of equipment throughout other modules as well.

<p class="slate-p " ><p class="slate-p " >The <em class="slate-italic">Service</em> API&apos;s are interfaces to reading and interacting with service information within the NetView system.</p></p><p class="slate-p " ></p>

<p class="slate-p " >This section provides the necessary details for usingthe OAuth API to authenticate users and access system resources securely. Follow the steps outlined to integrate your application with our authentication system. Refresh tokens are currently not used, but planned to be an option in a future additon. Unless otherwise noted, all access tokens are valid for 1 hour upon generation.</p><h2 class="slate-h2 " >Token Generation</h2><p class="slate-p " >See API Reference <a href="67813b0233b3c89b3be49fe3/67813b0e12bd360b8b57ed45/67813b16d45e47dc083bdfea" target="">here</a>.</p><h2 class="slate-h2 " >Using the Access Token</h2><p class="slate-p " >Once you have obtained the access token, include it in the `Authorization` header for all API requests to access protected resources.</p><h3 class="slate-h3 " >Example of Using the Token</h3><p class="slate-p " ><strong class="slate-bold">Headers:</strong></p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative"><code class="slate-code">Authorization: Bearer &lt;access_token&gt;</code></div></li></ul><p class="slate-p " ><strong class="slate-bold">Sample Request</strong>:</p><div class="code-block-wrapper"  style="width:60%" ><div class="code-block-header">Plain text</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden">GET /api/resource HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json </textarea><code class="language-plainText keep-markup drop-tokens"></code></pre></div><h2 class="slate-h2 " >Usage Guidelines</h2><p class="slate-p " >1<strong class="slate-bold">. Authentication Flow</strong>:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Call the <code class="slate-code">POST /oauth/token</code> endpoint to obtain an access token.</div></li><li class="slate-li " ><div style="position:relative">Include the token in the `Authorization` header of subsequent requests.</div></li></ul><p class="slate-p " ><strong class="slate-bold">2. Token Security</strong>:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Keep the access token secure and avoid exposing it in URLs or logs.</div></li></ul><p class="slate-p " ></p><h2 class="slate-h2 " >Security Recommendations</h2><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Use HTTPS</strong>: Ensure all API requests are made over secure HTTPS connections.</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Secure Access Tokens</strong>: Never expose access tokens in URLs or logs.</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Token Expiry</strong>: Implement logic to refresh tokens when they are near expiry.</div></li></ul><p class="slate-p " ></p><p class="slate-p " ></p>

This section provides the necessary details for usingthe OAuth API to authenticate users and access system resources securely. Follow the steps outlined to integrate your application with our authentication system. Refresh tokens are currently not used, but planned to be an option in a future additon. Unless otherwise noted, all access tokens are valid for 1 hour upon generation.

Once you have obtained the access token, include it in the `Authorization` header for all API requests to access protected resources.

Sections