# Breaking Changes for REST plugin

***

## 3.0.1 <a href="#id-3-0-1" id="id-3-0-1"></a>

09 Apr 2026

### RESTHost XML date-time serialization

#### What breaks?

This breaking change affects the XML responses sent by RESTHost services that use XML content types (`application/xml` or `text/xml`) with date-time properties. The format of date-time values in XML responses has changed. Incoming requests are not affected — Linx handles both the old and new format.

Previously, date-time values were serialized using the `DateTimeOffset` structure:

```xml
<DateAndTime xmlns:a="http://schemas.datacontract.org/2004/07/System">
  <a:DateTime>2026-03-18T04:37:16.196Z</a:DateTime>
  <a:OffsetMinutes>0</a:OffsetMinutes>
</DateAndTime>
```

Now, date-time values are serialized in the standard ISO 8601 format:

```xml
<DateAndTime>2026-03-18T04:37:16Z</DateAndTime>
```

#### Why?

The previous format used .NET's internal `DateTimeOffset` XML serialization, which does not conform to the format expected by the OpenAPI specification. The new format follows the standard ISO 8601 representation.

#### How to fix it

If you have clients that parse XML responses from a RESTHost service and depend on the previous `DateTimeOffset` structure (with `DateTime` and `OffsetMinutes` child elements), update them to parse the standard ISO 8601 date-time format instead.

***

## 2.0.0 <a href="#id-2-0-0" id="id-2-0-0"></a>

11 May 2023

### REST Multipart form data: Binary part

```
requestBody:
  content: 
    multipart/form-data: # Media type
      schema:            # Request payload
        type: object
        properties:      # Request parts
          myFile1:       # Part 1
            type: string
            format: binary
```

#### What breaks?

This breaking change only affects REST requests using multipart form data. Any form data containing a binary part (as Part 1 in the code section above) won't work after upgrading to this version of the plugin.

#### Why?

Previously, binary parts of multipart form data expected a Base64 string in Linx. This upgrade corrects this, and binary parts now expect binary content.

#### How to fix it

This can be fixed in one of two ways:

1. Change the REST service spec to expect a Base64 part instead of a binary part in its multipart form data.
2. Change the request to send binary content instead of a Base64 string.

**Please note:**\
ASP.NET Core requires binary parts to have a filename specified on the request. If no filename is provided on the request, that part will be sent through as null.

![Multipart encoded body editor with binary part](/files/nYi98IiFhCInYJKSkEjt)

In contrast to binary parts, Base64 parts require ***no*** filename in the request.

![Multipart encoded body editor with Base64 part](/files/4nVwPWA1qtRRjIojSHmq)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.linx.software/releasenotes/plugins/rest/breaking-changes.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.