BENNING Test Equipment Cloud (BTEC) employs the REST architectural style to interact with its services and resources. This documentation is interactive, allowing you to test and see first-hand how our system operates.

By adhering to REST principles and utilizing JSON for data exchange, standard HTTPS methods for actions, and HTTPS response codes for status reporting, BTEC ensures a robust, scalable, and intuitive API that developers can interact with efficiently and effectively.

Getting Started

To utilize these interactive features, follow the steps below:

Authentication

• Generate an access token for your active BTEC sandbox account on the Administration page under the API Access tab.
• You can customize the permission scope for different clients when creating/editing API tokens.
• By default, tokens are created for a sandbox account. To switch to a production account, uncheck the Test environment option when creating a new API access token.
• You can set an expiration date for your tokens. Empty expiration date will keep token valid until manually deleted.

API References

Use the following endpoints to get access to your data:

• Sandbox account: https://sandbox-api-btec.benning.de
• Production: https://api-btec.benning.de

Important: We highly recommend testing your code on a sandbox account before switching to a production account.

Authorization

After obtaining the token, proceed to the Authorize form on the API References page (a green highlighted button). This will enable interactive features.

Use the token in each request header as follows:

curl -H "Authorization: Token TOKEN" https://api-btec.benning.de/api/v1/...

HTTP Methods

BTEC supports the following HTTPS request methods:

• GET: Retrieves resources.
• POST: Creates resources or connections.
• PUT: Replaces objects, generates files or reports.
• DELETE: Deletes resources.
• PATCH: Updates parts of an object without replacing the entire resource.

Response Codes

The API uses standard HTTPS response codes to indicate the success or failure of a request:

HTTP Response Code	Description
200	Successful request
201	Resource successfully created
400	Bad request due to incorrect or missing parameters
401	Authorization error (invalid token)
412	Precondition failed
413	Permissions error
426, 427	License expired error
451	The BTEC is under maintenance.
500	Unexpected server error

Some request required additional information in query parameters or request body. If BTEC received invalid request the error will be returned. Error responses contain a description field with a details of the error.

If the query parameter has additional "*required" hint in description, such parameter is mandatory. All fields without this mark are "optional". For example, if no "search" parameter is provided, all items in the list will be retrieved according to limit. Sorting and pagination parameters can be used independently or together with the search.

Near each parameter there are additional information: a short description, the type of the input value, (body) or (query) parameter type, example input JSON value. In some descriptions/endpoints we use "Dut", what means "Device under test".

Filter options for lists

For more efficient data retrieval, use advanced filters. Filtering is available in GET list requests for customers, devices, overdue devices, test results, projects, and the user list.

The ordering keyword specifies the sorting order of the list results. ordering=name will define ascending order by name field, and ordering=-name - descending order.

To filter customers, devices, overdue devices by one or more fields, append & + property key id + = + filter keyword + value (in quotes) to the end of the GET request. For example, to find all devices with designation (device property key id = 4023) that equals "Office1" use the following endpoint: GET /data/devices/all/?enabled=[4021,4023]&4023=equals"Office1".

To combine multiple values for a single property, use logical operators (OR/AND) with escape characters. For example, to find all customers with name (customer property key id = 2531) that begins with "Benning" and does not contain "2025", use the endpoint: GET /data/customers/all/?enabled=[2531]&2531=startsWithAND"Benning"\notContainsAND"2025".

To filter test results, projects, and sub-users, use the field name instead of a property key id. For example, to find projects that were updated on the 7th of April, 2025 use the endpoint GET /project/viewset/?updated_time=sameDate"2025-04-07".

As an option, it is possible to combine filters on a single or multiple fields. For example, to find devices that were tested (last tested date property key id = 4025) on 03.04.2025 and department (property key id = 4027) is "Fert.1" in descending ordered by ID Barcode(4018), the url will be like GET /data/devices/all/?enabled=[4021,4018,4025,4027]&4025=sameDate"2025-04-03"&4027=equals"Fert.1"&ordering=-4018.

Special filter keywords:

Keyword condition	Field data type
equals	Number, Text
sameDate	Date
notEquals	Number, Text
notSameDate	Date
startsWith	Text
greaterThan	Number
newer	Date
notStartsWith	Text
greaterThanOrEquals	Number
newerOrSameDate	Date
endsWith	Text
lessThan	Number
olderThan	Date
notEndsWith	Text
lessThanOrEquals	Number
olderOrSameDate	Date
contains	Text
notContains	Text

JSON Data Format

All data exchanged with the BTEC API is in JSON (JavaScript Object Notation), a lightweight, human-readable format that is easy to parse and generate.

Rate Limiting

The API enforces a rate limit of 5 requests per second per access token. If this limit is exceeded, a 429 Too Many Requests error will be returned.

Breaking Changes Policy

We are committed to the continuous improvement of our API. Any deprecated features or breaking changes will be announced at least 3 months in advance via email before being applied to production. To ensure compatibility, we recommend designing integrations to handle unexpected changes, such as new fields or enum values.