.png)
A REST API across the whole ERP: styles, customers, orders, pick tickets, inventory, WMS, WIP, invoices, RMAs, reports and integrations. Read and write, JSON in and out, regional base URLs, an OpenAPI document, and a 90-day deprecation policy.
Open API
Styles, customers, orders, pick tickets, inventory, WMS, work in process, invoices, RMAs, reports and the integrations that sit on top of them. JSON in, JSON out, read and write, with public documentation, a downloadable OpenAPI document and a written deprecation policy. It is the same API Live Excel and the Claude, ChatGPT and Grok connections are built on.
A RESTful service that exposes the AIMS360 ERP to your own code and to the tools you connect to it. Requests take a JSON body or query string parameters and responses come back as JSON. The public documentation at api.aims360.io is published as a Postman collection, includes a link to download the OpenAPI document, and as of September 2026 covers 33 modules and roughly 790 endpoints.
It is not read-only. The collection carries GET, POST, PUT, PATCH and DELETE methods across its modules, so an integration can create an order, update a customer or receive a shipment, not only pull a report. What a given connection is actually allowed to do is set by the module permissions on the AIMS360 user it authenticates as.
The modules in the public collection, with the number of documented endpoints in each as of September 2026. Counts move as the API grows; the module list is the part to plan around.
| Module | What it handles | Endpoints |
|---|---|---|
| Codes | Reference data: bin location categories, body codes, credit codes, custom fields, countries, currencies, and the other coded lists the rest of the system keys against | 144 |
| WIP | Work in process: cut tickets, vendor purchase orders and garment dye, the production that has not landed as stock yet | 84 |
| References | Lookups other modules depend on | 57 |
| Styles | Style master, colors, sizes and the attributes that hang off them | 52 |
| Customers | Accounts, contacts, terms, ship-to addresses | 46 |
| Pick tickets | Picking, packing and the shipment side of an order | 39 |
| Orders | Sales orders across wholesale, DTC and EDI | 36 |
| Inventory management | On hand, available and adjustments at style, color and size | 34 |
| WMS | Warehouse operations and bin level movement | 25 |
| App integrations | QuickBooks customer and invoice sync, GL batches, install and revoke | 20 |
| Reports | Named report endpoints such as style costing, allocation details and invoice reports | 20 |
| RMA | Return merchandise authorizations, receipts and credits | 16 |
| Price sheets | Wholesale and retail price lists | 14 |
| Invoices | Invoice creation, retrieval and reporting | 13 |
| Materials | Fabric, trim and raw material records | 9 |
| Scheduled jobs | Jobs the system runs on a schedule | 8 |
| Shipping integration | Carrier and label exchanges | 7 |
| Notifications, payments | System notifications and payment records | 6 each |
| Colors, Shopify, authentication | Color master, the Shopify connection, and token generation | 5 each |
| 3PL, Aqua, documents, vendors, system jobs | Third-party warehouse exchange, the ExportData reporting endpoint, document storage, vendor master, system-level jobs | 4 each |
| Company, chargebacks, factors, import data, sales reps | Single-purpose modules for company settings, chargeback records, factor records, data import and sales rep records | 1 to 2 |
There is also a cache management module used by integrators, and a set of HTTP response code and per-module error code references. The full tree, with request and response fields for every endpoint, is in the public documentation.
Two models, both ending in a bearer token. Which one you use depends on whether your code is acting as your company or on behalf of an individual user.
POST client_id, client_secret, username and password as form URL encoded values to the token endpoint on your regional base URL. The response is a bearer token, which you send on every subsequent call. This is the path for integrations, scheduled syncs and Live Excel workbooks.
Redirect the user to the AIMS360 authorization page at auth.aims360.rest with your client ID and a callback URL on your own site. After the user signs in, you receive an authorization code at the callback and exchange it for a bearer token. This is the path for an app that acts on behalf of a signed-in AIMS360 user rather than as the company.
| Item | Where it comes from |
|---|---|
| API user | One AIMS360 user account designated to run API calls. An admin or the primary account is recommended, because it is the one least likely to be deleted. Everything running under that user's ID stops if the user is removed, including reports, dashboards and integrations. |
| Module permissions | Set on the API user. The API returns what that user is permitted to see and do. When a call returns less than expected, this is the first thing to check. |
| Email validation | The API user account must be email validated, or it cannot be used for API access at all. |
| Client ID and secret keys | On the AIMS360 License screen, reached from the user initials at the top right. There is a primary and a secondary secret key. |
| Access token | Generated under User settings, API tab, Generate Access Token, with a sign-in challenge and a copy-to-clipboard. Used to look up token details and to configure Live Excel. |
| Key regeneration | Restricted to the primary admin user, or done with support, because a regenerated key breaks every integration that used the old one. |
The token details endpoint takes an access token and returns your five-character account code, your client ID and the region your tenant is on, which is how a new integration learns which base URL to use.
AIMS360 publishes a separate base URL for each tenant region and recommends calling the one your tenant sits on for the fastest response. The token details call tells you which. Support can confirm it if you are unsure.
Endpoints carry a version in the path, and each module carries its own status of active or deprecated. Deprecated endpoints keep working during their notice period and show a deprecation note in the documentation.
At least 90 days' notice before discontinuing or removing major API features, with the API and version named and, where one exists, a replacement identified. Backward compatibility is attempted on a best-effort basis. Less than 90 days can apply if a security risk or a legal or third-party requirement forces a change.
The OpenAPI document is linked from the top of the public documentation, so you can generate a typed client or import the spec into your own API tooling rather than hand-write calls from the reference.
The API is not a side door. Several AIMS360 products are consumers of it, which is a reasonable proxy for how stable and complete it is.
| Product | How it uses the API |
|---|---|
| Live Excel reports | A workbook holds a bearer token derived from a user access token. Refreshing the workbook calls the API and pulls real-time data straight from the system. Brands build these themselves or have AIMS360 build them. |
| Claude, ChatGPT and Grok | Each connects through an MCP server that reads live orders, inventory and margin from the API, so a question typed into the assistant is answered from the ERP rather than from a stale export. |
| Shopify | The Shopify integration has its own endpoint group in the collection for the two-way connection between the store and the ERP. |
| 3PL warehouses | The 3PL module exports orders and pick tickets to a third-party warehouse and imports and processes the shipments that come back. |
| QuickBooks | The app integrations module carries the customer sync, invoice batch sync, GL batches and the install, setup and revoke calls behind the QuickBooks connection. |
| Your own tools | Anything a brand builds against the public documentation: a warehouse dashboard, a rep-facing order screen, a nightly data feed into a BI tool. |
AIMS360 also allows read-only ODBC and OLEDB connections to a company's own SQL database. That is a separate capability with separate credentials, and the two get confused. Here is the difference.
| The API | Direct database (ODBC or OLEDB) | |
|---|---|---|
| What it is | A REST service with documented endpoints, request and response shapes, and a permission model | A connection your own tools open to your SQL database |
| Authentication | Bearer token from client credentials or an access token | Server name, login and password issued by support |
| Read or write | Both, subject to the API user's module permissions | Read only, configured that way at issue |
| Who it suits | Integrations, apps and automations that need to create or update records, and anyone who wants a stable contract | An analyst who wants raw tables in a BI tool and will write their own SQL |
| What changes underneath | Governed by the deprecation policy | Table structures can change with releases; there is no versioned contract |
Constraints and behaviors we would rather you heard from us.
| Constraint | Detail |
|---|---|
| Plan availability | API access depends on your plan. Confirm with your implementation manager before scoping an integration. |
| Permissions are the ceiling | The API cannot return or change anything the API user is not permitted to. Short or empty responses are usually a permissions problem, not an API problem. |
| Deleting the API user | Stops every report, dashboard and integration running under that user. Pick an account that will outlast the people who set it up. |
| Regenerating a key | Breaks every integration using the old key at once. That is why it is restricted to the primary admin. |
| Use the regional base URL | The generic endpoint works, but the regional one is faster and is what the documentation recommends. |
| Test first | A sandbox and test environment is available so an integration can be exercised against non-production data before it touches the live company. |
| Counts drift | The module and endpoint counts on this page were taken from the public collection in September 2026. The documentation is the source of truth for what exists today. |
API questions we get from apparel and consumer brands and the developers who work with them.
Yes. The AIMS360 API is a RESTful service that accepts JSON request bodies or query string input and returns JSON. The public documentation at api.aims360.io covers 33 modules and roughly 790 endpoints as of September 2026, including styles, customers, orders, pick tickets, inventory, WMS, WIP, invoices, RMAs and reports. An OpenAPI document is available for download from the documentation.
Both. The collection includes GET, POST, PUT, PATCH and DELETE methods across its modules, so integrations can create and update records as well as read them. What a given API user can actually do is governed by the module permissions on that user account.
With a bearer token. For server-to-server use, POST your client ID, client secret and an AIMS360 username and password as form URL encoded values to the token endpoint and use the returned bearer token on every call. For a third-party application acting on behalf of a user, there is an OAuth-style authorization code flow: redirect the user to the AIMS360 authorization page with your client ID and callback URL, receive a code, and exchange it for a bearer token.
The one for your tenant region. AIMS360 publishes separate base URLs for West US and East US tenants, and recommends using the regional one for the fastest response. The token details endpoint tells you which region your account is on. If you are unsure, support can confirm it.
Yes. The public documentation is published in Postman at api.aims360.io and includes a link to download the OpenAPI document, so you can generate a client in your language of choice or import the spec into your own tooling.
An admin or the primary account, the one least likely to change. Everything that runs under that user's ID stops if the user is deleted, including reports, dashboards and integrations. The account must be email validated, and it must hold the module permissions the API calls need, or calls will not return what you expect.
AIMS360 gives at least 90 days' notice before discontinuing or removing major features from the API, names the API and version being deprecated, and where possible provides a replacement. Backward compatibility is attempted on a best-effort basis, and less than 90 days may apply where a security risk or a legal or third-party requirement forces a change.
Live Excel reports, which refresh a workbook from the API using a bearer token. The Claude, ChatGPT and Grok integrations, which use MCP to answer questions about live orders, inventory and margin. The Shopify, 3PL warehouse and QuickBooks connections, which each have their own endpoint groups in the collection. Anything a brand builds itself against the public documentation.
API access depends on your plan. Ask your implementation manager or account team which tier you are on and whether the API is enabled, and they will confirm what is included before you build against it.
Yes. AIMS360 offers a sandbox and test environment so an integration can be built and exercised against non-production data before it touches the live company. See the sandbox and test environment page for what it covers and how to request one.
Name the system, the direction the data moves, and how often. We will tell you which modules it touches, whether a pattern already exists, and what the API user needs to be able to see.
