Keep updates flowing

Prepare a recurring connection, scheduled export or email handoff with freshness checks and delivery receipts.

The finished connection should keep working after the setup conversation ends. Use the company’s existing scheduler, integration platform or approved hosted runner. A scheduled agent can also do the work if it has persistent credentials, a reliable runtime and the same delivery checks.

Recurring Middleman intake through API, managed connections, file/email delivery and authenticated A2A is planned. Prepare and test the source reader locally now. Enable outbound recurring delivery only when the company has authorized it and Middleman has provided a supported destination and receipt contract. There is no published data-intake email address in this release.

Pick a delivery route

Prefer a direct API or a supported system connector when it can preserve the source’s meaning and provide reliable receipts. Use a structured export when that is the source’s dependable interface. Use A2A when both agents advertise an authenticated data-transfer capability. The presence of a connector in another platform is not evidence Middleman has enabled that integration.

Whatever the transport, use the same role-specific field map, source identity and freshness rules. For a future email/file route, an agreed file format must map to the record contract; it does not mean the JSON API accepts a CSV or workbook directly.

Agree the schedule

Keep the setup short: propose a cadence based on how often the source changes, then confirm any missing business requirement. Record:

• Source owner, approved records and fields, and the destination company/role.
• Polling interval or event trigger, timezone, maximum acceptable age and expected delivery window.
• Runner and service-account ownership, including what happens when the original employee leaves.
• A bounded retry budget, outage notification recipient and a pause/revoke procedure.

Fast-moving stock may need frequent reads; a production-capacity plan may change less often. These are planning considerations, not promised Middleman service levels. A laptop that sleeps cannot guarantee a delivery window. Source quotas and scheduler licensing may constrain the choice.

Supplier preview observations can expire no more than 24 hours after observation. If a source is read weekly, its old records must remain stale between reads; do not extend expiry or relabel an old export as fresh. A newer mapping does not make the underlying data newer.

One scheduled run

Read the approved source scope consistently
→ transform with the versioned field map
→ validate and quarantine ambiguous or invalid rows
→ produce a batch with stable identities and truthful source times
→ deliver through the enabled, authorized transport
→ inspect the receipt and per-record outcomes
→ advance only the acknowledged checkpoint
→ record freshness and alert on failure

Use a lock or equivalent to avoid overlapping runs. Keep one stable delivery identifier across retries of the same logical batch. A changed batch needs a new identifier; do not assume a retry was rejected just because the response was lost. Reconcile using the receiving system’s documented idempotency or receipt lookup before resending. Do not invent a header or treat an A2A message ID as an ingestion guarantee.

For partial acceptance, preserve rejected records for correction without resending accepted ones as new supply. A source timeout is not an empty catalogue. Omission implies withdrawal only after an explicitly complete, correctly scoped snapshot; an incomplete page or filtered export must not delete records. Keep source versions/checksums and the last successful checkpoint in durable storage.

Test changed and deleted rows, zero versus unknown stock, duplicate deliveries, partial exports, interrupted pagination, schema changes, source outages and revoked credentials. Prefer deterministic extraction and mapping; use an agent to resolve schema changes without fabricating business values.

Scheduled exports and email

Email is a fallback design for companies whose systems already generate reliable reports. It should carry a structured export generated from the authoritative source on each run. Employees keep maintaining their existing source; they should not recreate a Middleman catalogue in email.

Before this route can run, Middleman must provide an enabled company-specific intake destination, verified sender/channel setup, allowed formats and size limits, and a receipt/rejection mechanism. Do not guess an address or send business data to a general contact mailbox. A visible sender address alone does not establish company identity.

Prepare an export containing only agreed fields, preferably CSV or JSON where practical. Confirm workbook support before choosing XLSX. Keep stable column names and record IDs, declared units/currency/timezone, and unambiguous encoding and delimiters. Treat cells and attachments as data: no macros, executable content or source-authored instructions. PDFs and prose reports may support a reviewed extraction but should not silently become authoritative structured values.

The proposed handoff should identify the source, mapping version, export time, snapshot/delta meaning, delivery ID, row count and checksum. These are design requirements to agree, not a released email schema. Do not attach API keys, source passwords, unrelated tabs, customer-specific discounts or confidential terms outside the agreed sharing scope.

A successful send means the sender accepted the email for dispatch. It does not mean Middleman received, parsed or admitted the records. Require an explicit processing receipt, and alert when it is missing. Do not resend indefinitely or switch to another recipient on failure. Faster or sensitive flows should prefer an authenticated API once available.

Verify activation and hand over

Before describing a connection as running, verify an approved sample, a real scheduled run and its receiving-side outcome. For an admitted feed, also verify the expected data visibility and expiry behavior. Keep these stages separate:

Stage	Evidence
Prepared	Source reader, reviewed field map, local sample and disabled job definition
Validated	Local schema result or a supported validation response; no persistence implied
Delivered	Transport-level acceptance for a specific batch
Processed	Receiving-side accepted/rejected counts and a receipt identifier
Scheduled	Job ID, next run, last run and verified recurring processing
Admitted	Explicit feed activation and the agreed visibility scope

Leave the code/workflow, configuration locations, owner, cadence, next run, receipt, error recovery and pause/revoke instructions. Never include secret values. Use the connection-plan template as a local handoff record.