Custom Logs (API)

If you want to send custom logs to the Middleware backend, you can use the provided API. This documentation covers how you can use the API to send the custom logs to the Middleware backend and how the data can be accessed via the Middleware dashboard.

Before you begin

• Endpoint: https://demo.middleware.io/v1/logs
• Auth: pass your Middleware API key in the Authorization header.

Endpoint

1POST https://demo.middleware.io/v1/logs

Authentication

Include your Middleware API Key in:

1Authorization: <MW_API_KEY>

Sample cURL

You can refer to this sample curl request to understand how to ingest custom logs to Middleware. Request Body fields are explained in the next section.

1curl -X POST "https://demo.middleware.io/v1/logs" \
2  -H "Accept: application/json" \
3  -H "Content-Type: application/json" \
4  -H "Authorization: <MW_API_KEY>" \
5  -d @- << 'EOF'
6{
7  "resource_logs": [
8    {
9      "resource": {
10        "attributes": [
11          { "key": "mw.resource_type", "value": { "string_value": "custom" } },
12          { "key": "service.name",    "value": { "string_value": "nginx-123" } }
13        ]
14      },
15      "scope_logs": [
16        {
17          "log_records": [
18            {
19              "severity_text": "WARN",
20              "body": { "string_value": "upstream server is not accepting request" },
21              "severity_number": 11,
22              "attributes": [
23                { "key": "server", "value": { "string_value": "nginx" } }
24              ],
25              "time_unix_nano": 1759750270000000000
26            }
27          ]
28        }
29      ]
30    }
31  ]
32}
33EOF

Understanding resource attributes

resource_logs → resource → attributes

Understanding log records

resource_logs → scope_logs → log_records

Verify delivery

Once you send data to the Middleware backend, you can access verify the data from the logs section. It can be further filtered using the custom attributes you have used in the cURL request.

For example, in the sample cURL request, we have used mw.resource_type = custom.

Troubleshooting

• 401/403 (auth): Use header exactly Authorization: <YOUR_MW_API_KEY> (no “Bearer”). Include mw.account_key in resource.attributes and ensure key/account match.
• 400 / schema issues: JSON must be valid. Required: mw.account_key, mw.resource_type="custom", body.string_value, time_unix_nano (number). Keep exact casing (string_value, not stringValue).
• Logs not visible: time_unix_nano must be nanoseconds (≈19 digits), not ms. Widen the time range and start with filter mw.resource_type=custom; refine by service.name if needed.
• Severity looks off: Use severity_text from {FATAL, ERROR, WARN, INFO, DEBUG, TRACE}. Keep severity_number within documented bands.
• Batch too big / 413 / flakiness: Send smaller batches (e.g., 500–1000 log records) and add retry with exponential backoff for 429/timeouts.
• CORS/proxy/TLS hiccups: Call the endpoint from server/agent code (not browser). If behind a corporate proxy, trust its CA or bypass interception for demo.middleware.io.
• Endpoint/headers sanity check: POST https://demo.middleware.io/v1/logs with Content-Type: application/json and Accept: application/json.