Skip to main content

Node admin-api

The admin-api node provides direct access to the internal OneEntry API. It allows you to read and modify orders, pages, products, users, collections, and payment sessions directly from the integration stream — without manually writing HTTP requests.

Settings for the admin-api Node​

IMG2

1. Name​

A field for specifying the name of the node.
The name is displayed in the workspace and helps easily identify the node.
If left empty, the node will be called admin-api.

Example:

  • Node name: Create Payment Session

2. Type​

Selection of the API operation that will be called when a message passes through the node. This is a dropdown list with search functionality: operations are grouped by API sections, and their names are taken from the API node description in the interface language. If there is no translation in this language, the names are shown in the original language.

The set of operations depends on the version of OneEntry, so please refer to the dropdown list Type for the exact list. Operations cover:

  • pages and products — for example, "Page object update", "Searching for all product page objects with pagination and filters.", retrieving multiple products by IDs;
  • users — including searching for users;
  • attribute values — including updating attribute values for multiple entities at once;
  • orders — changing order status, applying status triggers, returns;
  • payment sessions — for example, "Payment session creation" and "Payment session update";
  • bonus balance — manual adjustment of the user's balance;
  • collection records — for example, "Retrieving all records belonging to a collection.".

After selecting an operation, the Query parameters and Request body fields are filled with an example from the API description — you will just need to substitute your values.

3. Query parameters​

Query parameters. The path and HTTP method are automatically taken from the selected operation, and they cannot be edited in the form. The values of path parameters (for example, record ID) are specified in this same field along with the URL request parameters.

The field uses Mustache syntax — values from msg can be inserted using {{variable}}.

Example (for the operation "Retrieving all records belonging to a collection."):

{
  "entityType": "orders",
  "entityId": "{{orderId}}",
  "langCode": "en_US",
  "offset": 0,
  "limit": 1,
  "marker": "delivery"
}

4. Request body​

The request body in JSON format. This field is displayed only for operations with POST, PUT, and PATCH methods. It supports Mustache for substituting data from msg.

Example (for the operation "Payment session creation"):

{
  "orderId": {{orderId}},
  "type": "session"
}

5. Input Schema​

The Input Schema block is displayed in the node settings and shows the structure of the data coming from the previous node in the stream. The schema is presented as pairs of "key — type," taking into account the nesting of objects.

If schema fields are present in the API description, textual descriptions are displayed next to them. These same descriptions are picked up by the code editor as hints when writing Mustache templates.

Example of Input Schema display:

payload
  └── order
        ├── id           (integer)  — Order ID
        ├── status       (string)   — Current status
        └── totalPrice   (number)   — Total amount

6. Execute Button​

The Execute button allows you to call the API request directly from the node editing form without running the entire stream.

How it works:

  • The server executes the entire stream from the beginning to this node, passing data along the chain according to the last published state of the stream.
  • If any function node along the way does not pass data further but has the Output Example (JSON) field filled, that data is used as test data.
  • In the case of a successful response, the API response is passed to the next node as a schema.
  • If the request returns an error, the schema is not passed to the next node.
info

Before using the Execute button, ensure that the stream is published. The server executes the chain based on the last publish state.

Impact on the schema:

The admin-api node initially has a response schema from the API description. When the Execute button is pressed, the schema is overwritten with the real response from the API. Fields that match the API description retain their textual descriptions.

7. Automatic invocation of read-only requests​

All admin-api nodes that perform read-only requests (GET) are automatically invoked:

  • when the Integrations page is opened,
  • when the stream is updated via the Publish button.

This ensures that the data schema in the next node is always up to date without manual triggering.

Usage Examples​

Example 1: Creating a payment session​

Node settings:

  • Type: Payment session creation
  • Request body: 
    {
      "orderId": {{orderEvent.order.id}},
      "type": "session"
    }

Result:
The node creates a payment session using the orderId from the incoming message and passes the new session data to the next node.

Example 2: Updating the order status​

Node settings:

  • Type: Updating the status of an order belonging to the order storage object
  • Query parameters: 
    {
      "id": {{orderId}}
    }
  • Request body: 
    {
      "status": "{{newStatus}}"
    }

Result:
The node updates the order status using data from the incoming message.

Example 3: Retrieving collection records​

Node settings:

  • Type: Retrieving all records belonging to a collection.
  • Query parameters: 
    {
      "entityType": "delivery",
      "entityId": "{{payload.id}}",
      "langCode": "en_US",
      "offset": 0,
      "limit": 10
    }

Result:
The node returns a list of collection records. Since this is a read-only request, the response schema is automatically loaded when the page is opened.