Technical reference

API environments

Navixy Repository API is available on multiple regional platforms to optimize performance and comply with data residency requirements.

Base URLs

URLs are given with the current API version number. See Versioning for more information about the numbering system.

Current URLs:

Region	Base URL	Data Location
Europe	https://api.eu.navixy.com/repo/v0	European data centers
Americas	https://api.us.navixy.com/repo/v0	US-based data centers

Environment selection

Choose the environment that:

1. Is geographically closest to your operations (to minimize latency)

2. Complies with your data residency requirements

3. Matches your existing Navixy platform subscription

Both environments offer identical API functionality, but may differ in:

• Response times based on your geographic location

• Data storage location (important for compliance with regulations like GDPR)

• Maintenance windows and update schedules

Note that in this and other articles about Navixy Repository API, {BASE_URL} is a placeholder for the URL you'll be using.

Methods

The API follows the OpenAPI standard with full CRUD for each object type:

Object	Main Methods
asset	create, read, update, delete, list
asset_type	create, read, update, delete, list
asset_link	create, read, update, delete, list, set, remove
inventory	create, read, update, delete, list
inventory_item	create, read, update, archive, delete, list, activate, pair, list models

Call patterns

Request format

GET requests

• Use for read-only operations that do not change data.

• Pass parameters in the URL query string.

Example:

curl -L \
  --request GET \
  --url '{BASE_URL}/inventory/read?id=123'

POST requests

Use POST requests with a JSON body when you need to:

• Create, update, or delete data

• Fetch data with complex filter parameters

• Perform bulk operations

• Send parameters as a JSON object in the request body with Content-Type: application/json.

Example:

{
  "id": 123,
  "data": {
    "key": "value"
  }
}

Response format

All API responses follow a consistent JSON format:

• HTTP status codes indicate success or failure

• Success responses include the requested data or confirmation (for 204 No Content, the body is empty)

• Error responses provide detailed error information in the JSON body

• List responses include pagination metadata when applicable

Example schema of a paginated response:

{
  "data": [
    {
      "key1": "value",
      "key2": "value"
    }
  ],
  "has_more": true
}

See the Pagination section for more information.

Errors

Navixy Repository API uses conventional HTTP status codes to indicate the success or failure of a request.

• 2xx: Request was successful.

• 4xx: Request failed due to client error (e.g., validation error, missing parameter).

• 5xx: An internal server error occurred (these are rare and typically indicate an issue on our side).

Error response format

When a request with the 400 status fails with the invalid_parameters code, the response body contains a structured error object that helps both users and developers understand and resolve the issue.

{
  "code": "invalid_parameters",
  "message": "One or more parameters are invalid.",
  "correlation_id": "1a2b3c4d-5678-90ab-cdef-1234567890ab",
  "errors": [
    {
      "parameter": "email",
      "code": "invalid_format",
      "message": "The email address format is invalid."
    },
    {
      "parameter": "password",
      "code": "too_short",
      "message": "Password must be at least 8 characters long"
    }
  ]
}

Pagination, search, filtering, and sorting

List endpoints in this API support fetching paginated data with flexible filtering and sorting options. You can use both GET and POST methods depending on the complexity of the query.

Pagination

All list endpoints return results in a paginated format:

{
  "data": [ ... ],
  "has_more": true
}

• data – array of objects. A list of items returned for the current page, based on the provided query parameters.

• has_more – boolean. Indicates whether more items are available beyond the current page. When false, the current result set is the final one, and no additional data can be retrieved using the same query parameters.

Query parameters

Name	Type	Nullable	Required	Description
q	string	yes	yes	A search query string
conditions	array of objects	yes	no	Advanced filtering rules. Used only in POST requests. See Filtering for more information.
limit	int	no	no	Maximum number of items to return (default: 100, max: 1000).
offset	int	yes	no	The index of the first item to return (default: 0).
sort	string	yes	no	Sort expression. Supports one or more fields. See Sorting for more information.

Search

The API provides flexible search capabilities to help you find specific resources quickly and efficiently. Search functionality is available across all list endpoints and can be combined with filtering and sorting for precise data retrieval.

To perform a basic full-text search (available for list endpoints), use the q parameter.

GET:

curl -L \
  --request GET \
  --url '{BASE_URL}/inventory/list' \
  --header 'Authorization: Bearer <YOUR-TOKEN>' \
  --data-urlencode 'q=geneva warehouse'

POST:

curl -L \
  --request POST \
  --url '{BASE_URL}/inventory/list' \
  --header 'Authorization: Bearer <YOUR-TOKEN>' \
  --header 'Content-Type: application/json' \
  --data '{"q": "geneva warehouse"}'

Filtering

For complex queries beyond basic search, use the conditions parameter in POST requests. The filtering system supports logical operators (AND, OR, NOT) and field-level comparisons (equality, range, set membership, etc.) for complex expressions.

Basic filtering structure

Filters are defined as condition objects with a type field that determines the comparison operation:

{
  "conditions": [
    {
      "type": "eq",
      "field": "status",
      "value": "active"
    }
  ]
}

Supported operators

Name	Description	Comment
eq	Equals	Checks if the field equals the given value
neq	Not equals	Checks if the field does not equal the given value
gt	Greater than	Checks if the field is greater than the given value
gte	Greater than or equal	Checks if the field is greater than or equal to the given value
lt	Less than	Checks if the field is less than the given value
lte	Less than or equal	Checks if the field is less than or equal to the given value
contains	Contains substring	Checks if the field contains the given substring
in	In list	Checks if the field value is within the given list of values
between	Between two values	Checks if the field value is between two values (inclusive)
and	Logical AND	All conditions must be true
or	Logical OR	At least one condition must be true
not	Logical NOT	Negates the given condition

Sorting

Control the order of results using the sort parameter. Sorting works with both GET and POST requests.

Sorting syntax

• Ascending order by a single field: sort=created_at

• Descending order by a single field: sort=-created_at (prefix with -)

• Multiple fields: sort=label,-created_at,id (comma-separated)

Versioning

The API follows industry-standard semantic versioning principles to ensure clear, predictable upgrades and stable integrations.

Versioning strategy

To make versioning transparent and intuitive, the version is directly included in the request URL:

https://api.us.navixy.com/repo/v{major}/{resource}/{operation}

For example:

https://api.us.navixy.com/repo/v0/inventory/list

The major version number is incremented only upon the introduction of breaking changes, such as:

• Changing the structure or format of responses

• Renaming or removing existing endpoints or their fields

• Modifying validation rules in a way that would reject previously valid requests

Documentation and migration

Every maintained API version is fully documented, containing the following:

• A version-specific reference

• A changelog outlining all updates

• Migration instructions to help you move from an older version to the latest one with minimal friction

The following methods may ease the migration:

• Using sandbox environments to validate new versions

• Running multiple versions in parallel during transitional periods

API automation tools

In the modern development environment, speed and precision matter. Automating your API interactions saves time, reduces errors, and helps you bring value to users faster. Whether you're building full-stack applications, setting up system integrations, or testing individual endpoints, this section introduces key tools that simplify and accelerate your work with Navixy Repository API.

Navixy supports both developers and non-developers by providing industry-standard tools and resources for interacting with the API. More integrations and tools will be added over time to support growing use cases and automation scenarios.

OpenAPI

Explore the full structure of Navixy Repository API using the OpenAPI standard.

• Use it to generate client SDKs in various programming languages.

• Import the definition into OpenAPI-based API documentation & testing tools.

• Perfect for documentation readers who want to explore and test endpoints without manual setup if the built-in documentation tools are insufficient for your specific needs

You can view the current version of the OpenAPI specification here.

Postman

Postman is a powerful API client used for testing and exploring APIs.

Navixy Repository API comes with a ready-to-use Postman Collection. Just import it, enter your credentials, and start making requests — no setup required. It's great for quickly learning the API and trying different operations in a sandbox environment.

Should you encounter limitations with the documentation's sandbox capabilities, we recommend exploring advanced Postman features or dedicated development environments for more complex testing scenarios.

Zapier

Zapier is a no-code automation platform that connects Navixy Repository with thousands of third-party apps.

Set up workflows (called "Zaps"), which contain triggers in Navixy Repository that automatically result in actions in other systems.

It's perfect for business users and analysts who need automation without writing code. For example, it allows you to log tracker activity to a spreadsheet or notify your team in Slack when a specific event occurs.