.NET client

The Pulse .NET client is the official client library for integrating .NET applications and services with Pulse.

It is intended for automated and long-running integrations where data from systems such as ERP, MES, WMS, historians, or custom applications needs to be sent to Pulse without manual transfer.

The client communicates with the Pulse backend through the REST API and uses Bearer-token authentication.

When to use the .NET client

Use the .NET client when:

• the source system or integration service is built on .NET;
• data should be sent to Pulse automatically;
• the integration runs continuously or on a scheduled basis;
• the source system needs a typed client instead of manually constructing HTTP requests;
• the integration needs to send data from the Food & Beverage model through resource-specific services.

For file-based onboarding or smaller manual data exchanges, use the Excel template instead.

How it fits into an integration

A typical integration flow is:

ERP / MES / WMS / custom .NET application
                |
                v
          Pulse .NET client
                |
                v
          Pulse backend
                |
                v
              Pulse

The source system prepares the business data, maps it to the Food & Beverage model, and passes it to the appropriate .NET client service.

The client serializes the request and sends it to the corresponding Pulse REST endpoint.

Pulse then validates, stores, and processes the submitted data.

Configuration and authentication

The client requires:

• the Pulse host URL;
• a valid Bearer token.

The client configuration reads these values from:

host:url
host:token

The configured HTTP client sends requests to the Food & Beverage service and adds the Bearer token to each request.

Registering client services

The .NET client registers resource-specific services through dependency injection.

Examples include:

ISiteService
IProductionLineService
IMachineService
IVesselService
IProductService
IRecipeService
IMaterialService
IMeasurementService
IRunService
IReadingService
IWorkOrderService
IComplaintService

Each service represents one Food & Beverage resource or integration area.

Working with resource services

Resource services expose typed operations instead of requiring the integration to build HTTP requests directly.

For example, the site service provides operations for:

• insert;
• update;
• partial update;
• delete;
• query;
• select.

A site is represented by a typed DTO:

new InsertSiteDto
{
    Code = "SITE-01",
    Name = "Ljubljana"
}

The service then sends the corresponding request to the Pulse Food & Beverage API.

Conceptually:

var siteService = ...;

await siteService.Insert(new InsertSiteDto
{
    Code = "SITE-01",
    Name = "Ljubljana"
});

Use the corresponding service for each resource being integrated.

Supported operation patterns

The client supports the main API operation patterns used by Food & Beverage resources:

insert
update
patch
update-batch
delete
query
select

The exact operations available depend on the resource.

Use the resource-specific service interface to determine which operations are supported.

Partial updates

Where supported, the client can send partial updates without resubmitting the complete resource.

A patch identifies the target record and provides only the properties that need to change.

Use partial updates only where the resource service exposes patch support.

Error handling

The client checks the HTTP response returned by Pulse.

If the backend rejects a request, the client raises a Pulse-specific exception containing information about the failed service operation and the response returned by the backend.

Integration code should handle these failures and inspect the backend validation response before retrying.

Do not automatically retry requests that fail because of invalid data, missing references, unsupported values, or other validation errors.

See Validation and Troubleshooting.

Sending raw data to Pulse

The primary role of the .NET client is to send raw source-system data into Pulse.

Depending on the Food & Beverage integration, this can include:

• sites and production lines;
• machines and vessels;
• products and recipes;
• materials and suppliers;
• runs, batches, and lots;
• consumption and output;
• readings and settings;
• line time and events;
• work orders and complaints.

The client does not calculate Pulse analyses or business findings. Its role is to transport integration data to the Pulse backend.

Reading Pulse results

The .NET client can also support read-only access to Pulse results exposed by the backend.

This can be used when a customer application needs to display or consume results that Pulse has already calculated.

The .NET client does not create analyses itself and does not directly access internal Pulse services.

.NET client vs REST API

The .NET client uses the same Pulse backend API as a direct REST integration.

Choose the .NET client when the integration is implemented in .NET and you want:

• strongly typed request and response models;
• resource-specific services;
• built-in HTTP serialization;
• consistent authentication handling;
• common error handling.

Use the REST API directly when:

• the integration is not written in .NET;
• another platform or programming language is being used;
• direct HTTP integration is preferred.

The .NET client does not replace the REST API. It provides a .NET-friendly way to use it.

.NET client vs Excel import

The .NET client and Excel integration are intended for different integration scenarios.

Both approaches map data to the same Food & Beverage model.

Recommended next steps

1. Review Authentication.
2. Review the Food & Beverage data model.
3. Identify which resource services are required by the source system.
4. Configure the Pulse host URL and Bearer token.
5. Start with stable master data before submitting dependent operational data.
6. Use the API reference to confirm resource behavior and supported operations.