# Report Watch: n8n and Make integration examples

Reviewed against the Report Watch submission contract on October 10, 2026. Live checkout is now available, but signing in or returning from checkout does not itself confirm monitoring entitlement. This reference explains manual configuration and the shared request contract; it does not install or verify your customer's workflow. The [envelope JSON](https://reportwatch.mayd-it.com/examples/report-watch-envelope.json) and [CSV](https://reportwatch.mayd-it.com/examples/report-watch.csv) are fictional offline data fixtures with a fixed example date.

For an importable n8n workflow, use the separate [n8n setup guide](https://reportwatch.mayd-it.com/guides/n8n-csv-monitoring) and [workflow JSON download](https://reportwatch.mayd-it.com/examples/n8n-report-watch.json). That download has a manual trigger, one request attempt and a receipt classifier. It includes no credentials, automatic schedule, retry loop or downstream action. Keep it unpublished while configuring its protected credential and replacing its deliberately invalid placeholders. The guide records current verification status. Make remains a manual configuration recipe, not a tested blueprint.

## Access comes first

The public introduction uses reportwatch.mayd-it.com. A report token authorizes only its monitor. Monitoring requires an active, eligible report in an entitled workspace: confirmed live payment for public accounts, or separate owner/invited-pilot admission. Public signup alone does not enable monitoring. A login page or other HTML response is not an ingestion result, even if it has HTTP status 200.

Do not put the owner's Sites service credential, browser session, identity headers, scheduler secret, or account credentials in customer workflows. Keep each workflow disabled until its own end-to-end submission has been verified. The examples below describe the application's direct ingestion contract; any future gateway must have its own reviewed contract and access controls. Users with monitoring enabled can also use the signed-in dashboard's CSV upload. Losing entitlement or placing a workspace on hold stops future submissions; 402, 403 or 423 requires review, not repeated retries. Closing signup does not itself end an existing paid subscription.

## Shared request contract

Obtain the monitor ID and its report token when creating a monitor or using **Replace submission token** in the dashboard. The generated token is 64 lowercase hexadecimal characters representing 32 random bytes, with no prefix. The application stores only its SHA-256 hash. Replacing it invalidates the previous token. Store it in the workflow platform's protected credential facility, accessible only to operators who need to submit to that monitor. Keep it out of workflow exports, ordinary variables, logs, and screenshots.

| Setting | Value |
| --- | --- |
| Method | `POST` |
| URL | `https://reportwatch.mayd-it.com/api/ingest/<monitor-id>` |
| Authorization | `Bearer <report-token>`; one space after `Bearer` |
| Content-Type | `text/csv; charset=utf-8` |
| Idempotency-Key | Stable submission ID, nonblank and no longer than 128 characters |
| X-Report-Deadline | Exactly 13 digits: intended scheduled deadline in Unix milliseconds |
| Body | The raw, uncompressed UTF-8 CSV text |

Send the CSV itself, not JSON, base64, multipart form data, or a URL to a file. Do not add an `Origin` header or impersonated user identity. This machine endpoint uses the report token; `/api/reports/<id>/upload` is the separate signed-in dashboard route.

Application limits are 1 MiB of received bytes, 100 columns, 10,000 data rows, 100 UTF-16 code units per header before and after normalization, and 16,384 UTF-16 units per data cell. Each workspace permits 1,000 new checks per rolling 24 hours and 5,000 saved checks total. Saved failed checks count; identical retries do not consume another slot. Waiting does not clear the total-storage cap; contact support for export and retention review. CSV column names are trimmed and lowercased; duplicate normalized headers fail. Optional freshness checks examine every data-row date against the first accepted request's check time, not the report deadline. A date-only value means midnight UTC; timestamps need an explicit timezone. Raw CSV rows are processed in memory, but column names, check metadata, rules, fingerprints, and results are stored. Automatic metadata deletion is not implemented; the dashboard's latest-100 view is not a retention policy. The workflow platform may retain its own execution payloads, so configure its retention and access separately.

## Freeze the report period and artifact

Create and persist one immutable submission envelope when producing the report:

```json
{
  "monitorId": "11111111-1111-4111-8111-111111111111",
  "deadlineIso": "2026-10-12T16:00:00.000Z",
  "deadlineMs": "1791820800000",
  "revision": "v1",
  "submissionId": "rw:11111111-1111-4111-8111-111111111111:1791820800000:v1",
  "csv": "report_date,client,orders\n2026-10-12T15:45:00Z,Example client,12\n"
}
```

The ID above is a fictional monitor, not a credential. This dated example assumes a monitor created before October 12 with a **weekly Monday 09:00 America/Los_Angeles** schedule and a 15-minute grace period. October 12, 2026 at 09:00 PDT is `2026-10-12T16:00:00.000Z`, or `1791820800000`. Grace does not change that header to 09:15. The sample CSV passes rules requiring `report_date`, `client`, and `orders`, 1–10,000 rows, and a `report_date` maximum age of 24 hours when checked at that example deadline.

In a real recurring workflow, the report-producing job must persist the **intended scheduled occurrence** with its artifact. Convert that occurrence to milliseconds once. Do not derive it from `now`, the latest workflow execution time, or the monitor's advancing “next due” value when retrying. If a Monday report finishes Tuesday, it still names Monday's deadline.

The server accepts an actual occurrence under the monitor's current schedule, at or after monitor creation, and no later than the next upcoming occurrence. It permits older periods within that constraint. Seconds, ISO strings, deadline-plus-grace, and arbitrary timestamps fail. Do not add a fixed 24 hours or seven days to UTC timestamps to reproduce local schedules across daylight-saving changes. Report Watch resolves a nonexistent local time to the first valid local minute after it and uses only the earlier instant when a local time occurs twice. For example, Los Angeles 02:30 on March 8, 2026 resolves to 03:00 PDT, while 01:30 on November 1 uses the first 01:30. A workflow scheduler's own DST behavior must be checked before launch; it is not assumed identical. UTC monitor schedules avoid that conversion ambiguity.

Keep the CSV, deadline, monitor ID, and submission ID together in a durable retry record. A retry after a workflow restart must reload that record. Do not regenerate the report or its ID inside the retry loop. The ID is scoped to one monitor: a revision such as `v1` can be used in the composed ID only while that period's artifact remains identical. A corrected CSV, another period, or an intentional new check gets a new submission ID; a correction for an old period keeps the old period's deadline.

## n8n configuration example

The steps in this section are a manual node configuration recipe. For the separate importable export, follow the [n8n workflow setup guide](https://reportwatch.mayd-it.com/guides/n8n-csv-monitoring) and inspect its verification note. Confirm labels and result mapping in your installed version before enabling a workflow. Refer to the [official n8n HTTP Request documentation](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/) for Raw body, redirects and response options, and [HTTP credentials](https://docs.n8n.io/integrations/builtin/credentials/httprequest/) for protected Header Auth.

1. After the existing report-generation step, persist the submission envelope above using the intended occurrence supplied by that job. The fixture can be used offline; replace its ID, period, and CSV with actual report metadata only after customer ingress is approved. Convert an explicit UTC ISO value to milliseconds once with `String(Date.parse(deadlineIso))`, checking that the input is valid and the result is exactly 13 digits. This conversion does not calculate a schedule occurrence.
2. Configure an **HTTP Request** node for `POST` to the approved origin plus `/api/ingest/` and the envelope's `monitorId`. Use a protected Header Auth credential whose header name is `Authorization` and whose secret value is `Bearer <report-token>`.
3. Send `Content-Type: text/csv; charset=utf-8`, `Idempotency-Key: {{ $json.submissionId }}`, and `X-Report-Deadline: {{ $json.deadlineMs }}`. Select a raw text body mapped to `{{ $json.csv }}`. The HTTP node's input must be the persisted envelope, not newly computed values on each attempt.
4. Capture the HTTP status, response headers, and parsed JSON body. Disable following redirects. Route non-2xx responses and transport errors to the bounded retry/error branch below, rather than losing the original envelope or treating every error as a fresh report.
5. For HTTP 200, require the expected JSON result shape, including a `checkId`, the same `deadline`, and `status` equal to `passed` or `failed`. Route `failed` to the report owner's quality-review branch. Route `passed` with `late: true` to a late-report branch if timeliness matters. Store the returned `checkId` and classification alongside the submission envelope.

If using a full HTTP response object, inspect the parsed response **body's** `status`, not the HTTP status code field. Avoid a bare “retry on all errors” setting: the policy below distinguishes broken configuration, exhausted quota, failed data quality, and temporary transport failure.

The downloadable manual workflow stops after classifying `passed`, `quality_failed` or `review`; you must add any downstream routing deliberately. It does not implement the bounded retry policy below or durable envelope storage. Its explicit placeholders fail validation before submission. Select a protected credential yourself; a report token must never be written into the workflow JSON or saved envelope. n8n execution history, intermediate node data and CLI output can expose CSV inputs and response/header values, so review access and retention independently of Report Watch.

## Make configuration example

This is a module configuration recipe, not a tested Make blueprint. The [official Make HTTP documentation](https://apps.make.com/http) describes the current module and protected keychains. Confirm the installed HTTP module's mapping and error-handler behavior before enabling it.

1. After the scenario creates the CSV, save a durable record containing the same envelope fields. For each trigger, carry the intended report occurrence from the report job. Use the already-resolved `deadlineMs` string; do not map Make's current time into that header.
2. In **HTTP → Make a request**, use `POST` and the approved origin's `/api/ingest/<monitorId>` path. Store and supply the monitor token through the module's supported protected credential/connection mechanism. The resulting request needs exactly the Authorization header in the shared contract. If the available module cannot keep that value out of ordinary scenario data and exports, leave the scenario disabled until that credential path is resolved.
3. In the current HTTP module, choose **Custom** for Body content type, set Content type value to `text/csv; charset=utf-8`, and map the saved `csv` string as the body content. Older module versions may label this **Raw**. Map saved `submissionId` and `deadlineMs` to their headers. Disable redirect following. Do not select a multipart upload or map a file URL.
4. Parse a successful JSON response and use router filters for `status = passed` and `status = failed`, with a separate timeliness decision for `late`. Keep the HTTP response code and the check's JSON `status` separate.
5. Send connection errors and HTTP failures to an error-handler path that preserves the envelope. Resume/retry that saved request according to the table below; do not restart report generation to retry ingestion. Preserve unresolved failures in an operator-visible queue rather than dropping the bundle.

## Response and retry policy

| Outcome | Workflow action |
| --- | --- |
| HTTP 200, JSON `status: passed` | Record `checkId` and finish; inspect `late` separately. This proves the submitted CSV passed configured rules, not that a client received it. |
| HTTP 200, JSON `status: failed` | Record evidence and route for correction. Repeating the same request will return the saved failure. Send corrected content with a new ID and the same intended deadline. |
| HTTP 200, JSON `duplicate: true` | Use the saved result. This is a successful retry acknowledgement, not a new evaluation. Original `checkedAt`, rules, and `late` remain unchanged. |
| HTML, redirect, unexpected JSON, or absent check result | Treat as an access/routing problem; stop and review. Do not follow sign-in redirects or forward the token to another origin. |
| HTTP 400 | Fix the missing/invalid header, submission ID, or deadline. Do not blindly retry. |
| HTTP 401, 402, 403 or 423 | Stop and review the report credential, monitoring entitlement or workspace hold. Do not rotate credentials automatically. |
| HTTP 409 | Inspect the error: monitor paused or an ID reused with different content/deadline. Resume/review configuration or use a new ID for a genuinely new artifact; do not create a new ID merely to bypass a conflict. |
| HTTP 413 or 415 | Fix size, UTF-8 encoding, content type, or compression. This is not a transient failure. |
| Application HTTP 429 | Read the error: the rolling 24-hour submission quota or total saved-check cap is exhausted. Defer and notify the operator; waiting does not clear the storage cap and repeated requests will not help. The application does not currently provide a Retry-After header. |
| Network timeout, dropped response, or HTTP 5xx | Retry the identical saved request using the same ID and deadline. Use bounded attempts, for example three retries after about 5, 30, and 120 seconds with jitter, then retain it for operator review. |

A timeout does not establish whether the first request committed. Stable retries prevent duplicate saved checks. The duplicate lookup is reached only after token, paused-state, and deadline validation; rotating the token, pausing the monitor, or editing its schedule can therefore make an old retry fail. Coordinate configuration changes with pending workflows. Changing rules does not re-evaluate an existing submission ID; use a new ID for an intentional new check.

A late passing submission resolves only the incident for its named deadline. A later failed submission with a new ID can reopen that same period's quality incident. A pass for another period does not clear the older incident. Each report deadline can queue one quality-failure notification and one recovery notification. Later fail/pass revisions still update checks and incident state but do not repeat those messages. A missed-deadline notice is separately limited to one for that period; support notices are separate. Delivery depends on configured email and background maintenance, and queue insertion does not prove delivery. A late pass received before a missing-report sweep may prevent a missing incident from being created, so not every late report generates an alert. No strict delivery-time guarantee or live external integration is established by these examples.

## Offline verification and launch gate

The request path and checks above were reviewed against `lib/watch-server.ts`, `lib/watch-security.mjs`, `lib/csv-check.mjs`, `lib/schedule.mjs`, and the current README. The fixed sample's timestamp, schedule occurrence, and CSV result were evaluated with the actual local schedule and CSV validators. Existing server regression tests exercise the machine route, token rotation, missing/invalid deadlines, idempotent retry/conflict, period-specific recovery, and DST behavior. Those server and fixture checks do not establish n8n/Make runtime behavior or the hosted Sites gate. The separate [n8n guide verification note](https://reportwatch.mayd-it.com/guides/n8n-csv-monitoring#verification) records the importable workflow's current acceptance scope; Make has no tested blueprint here.

Before enabling a customer workflow, separately verify supported ingress, protected token storage, preserved CSV bytes and deadline headers, a first passing check, a failed CSV returning HTTP 200, same-request replay returning the original check, correction with a new ID, late-period recovery, restart/resume behavior, and token rotation. Use synthetic data and a dedicated test monitor. The public product page and narrow owner token-only hosted journey are already verified. These instructions do not install a workflow, prove live paid availability or complete a customer's end-to-end acceptance. Preserve the existing Site and use synthetic data for any remaining verification.