Create one or more new messages.

Used to identify which application logged this message. You can use this if you have multiple applications and services logging to the same log

A longer description of the message. For errors this could be a stacktrace, but it's really up to you what to log in there.

The hostname of the server logging the message.

The textual title or headline of the message to log. The first 50k characters are searchable.

The title template of the message to log. This property can be used from logging frameworks that supports structured logging like: "{user} says {quote}". In the example, titleTemplate will be this string and title will be "Gilfoyle says It's not magic. It's talent and sweat". The first 50k characters are searchable.

The source of the code logging the message. This could be the assembly name.

If the message logged relates to a HTTP status code, you can put the code in this property. This would probably only be relevant for errors, but could be used for logging successful status codes as well.

The date and time in UTC of the message. If you don't provide us with a value in dateTime, we will set the current date and time in UTC.

The type of message. If logging an error, the type of the exception would go into type but you can put anything in there, that makes sense for your domain.

An identification of the user triggering this message. You can put the users email address or your user key into this property.

An enum value representing the severity of this message. The following values are allowed: Verbose, Debug, Information, Warning, Error, Fatal

If message relates to a HTTP request, you may send the URL of that request. If you don't provide us with an URL, we will try to find a key named URL in serverVariables.

If message relates to a HTTP request, you may send the HTTP method of that request. If you don't provide us with a method, we will try to find a key named REQUEST_METHOD in serverVariables.

Versions can be used to distinguish messages from different versions of your software. The value of version can be a SemVer compliant string or any other syntax that you are using as your version numbering scheme.

CorrelationId can be used to group similar log messages together into a single discoverable batch. A correlation ID could be a session ID from ASP.NET Core, a unique string spanning multiple microsservices handling the same request, or similar.

Code can be used to include source code related to the log message. The code will typically span from a few lines before the line causing the log message to a few lines after. For now, all lines above 21 will be removed. This makes room for showing 10 lines before the logging line, the logging line, and 10 lines after the logging line. Don't include a very large string in this property since that will quickly make the entire messages exceed the max limit of 256 kb.

The log message category. Category can be a string of choice but typically contain a logging category set by a logging framework like NLog or Serilog. When logging through a logging framework, this field will be provided by the framework and not something that needs to be set manually.

Status code of the individual messages as if it were being created through the non-bulk endpoint. If a message was succesfully created, the status code will be 201 and location will contain an URL. If a message was ignored, the status code will be 200 and the location will be empty.

The location of the created message if StatusCode equals Created.