Resource Booking Overlap Evidence Report

What does Resource Booking Overlap Evidence Report do?

Find same-resource booking overlaps across exported schedules, including conflicts caused only by setup or teardown time. Upload normalized JSON rows or paste mapped CSV from the systems you already use. The report shows the two source bookings, the precise shared interval, and the original input row references for each finding.

This is useful for facilities teams reviewing meeting rooms, venue operators checking revised schedules, or equipment coordinators comparing exports from more than one booking source. Run it at a daily or weekly handoff, or after a schedule revision. It works with a finite snapshot you provide through the Apify input form or API. No calendar connection or external model is needed.

How to check a room or equipment booking export

1. Normalize each row to one opaque resource ID, one source ID and one booking ID. A booking using multiple resources needs one row per resource with distinct source booking identities; this Actor does not expand a multi-resource field.
2. Declare the exact resource IDs, source IDs, comparison window and snapshot coverage. Include relevant bookings and buffers crossing the window boundary.
3. Supply bookings as an array, including [] for an explicitly empty snapshot, or remove that array and supply bookingsCsv. Choose one format.
4. Run the Actor, inspect the summary and pair evidence, then download the full JSON, flat overlap CSV, identity findings CSV or standalone HTML.
5. Retain the export for review and run a new snapshot when the schedule changes.

The prefilled example includes a real overlap between two sources using the same booking ID, a harmless back-to-back booking, another resource and a cancelled booking. Replace the example with your own rows before using the result operationally.

Input format and coverage

See the input tab for full configuration options. Each booking requires these fields:

Field	Meaning
sourceId, bookingId, resourceId	Literal, nonempty opaque strings. Leading zeros and case are preserved.
start, end	Real RFC3339 instants with seconds and an explicit Z or numeric ±HH:mm offset. Start must precede end.
status	Exactly active or cancelled.
setupMinutes, teardownMinutes	Explicit nonnegative integer minutes, each at most 1,440. Use zero where no buffer applies.

Timestamps may contain one to three fractional second digits. Local times without an offset, unknown -00:00 offsets, leap seconds, invalid dates, recurrence, all-day fields and extra fields are rejected. Convert recurring or all-day events to individual timed rows in your source system before exporting; the Actor does not guess a timezone or expand events.

coverage must be complete, incomplete or unknown. Complete means that the rows cover every declared resource and source throughout [scopeStart,scopeEnd), including bookings whose setup or teardown enters the window. This is your statement about the snapshot; the Actor cannot independently establish export completeness. Unknown or incomplete coverage produces an unresolved finding even when no pair overlaps.

CSV accepts a UTF-8 BOM and standard quoting, including embedded commas. Quoted newlines are parsed, but values must pass the field rules: opaque IDs cannot contain newline or other control characters. The default headers are sourceId,bookingId,resourceId,start,end,status,setupMinutes,teardownMinutes. Supply bookingColumns to map every canonical field to a distinct export header. Only the eight mapped columns are accepted. Duplicate headers, missing columns, irregular records and ambiguous numeric cells fail validation. Header-only CSV is an explicitly empty snapshot. Remove the prefilled bookings array before entering CSV.

How are overlaps calculated?

For an active booking, the effective interval is [start - setupMinutes, end + teardownMinutes). The engine clips that interval to the declared window and compares it against distinct source-plus-booking identities on exactly the same resource. The end is exclusive: bookings that only touch are harmless unless their buffers overlap.

booking_overlap means the unbuffered booking intervals share time inside the window. buffer_overlap means only their expanded intervals share time. Output intervals use UTC and durations use integer milliseconds. Cancelled rows and active rows wholly outside the effective comparison window stay in the full evidence and counts but do not produce overlap pairs.

A booking identity is the exact pair of source ID and booking ID. The same booking ID in two sources is a separate identity. Identical repeated rows remain in the full evidence and compare once, with every row reference attached. If one identity has differing intervals, resources, status or buffers, every version stays visible and a conflicting identity finding is emitted. Pairs involving it have unknown severity. Such version pairs are evidence for review, rather than a count of confirmed distinct reservations. Multiple versions can therefore yield more than one evidence pair for the same two booking identities.

Output and downloads

Each completed run produces one dataset item containing the complete report, a rows array of overlap evidence pairs, a bookings array preserving all input rows, and identity or coverage findings. The dataset overview exposes the compared row and version counts, cancellations, out of scope rows, booking and buffer pair counts, ambiguous pairs and declared scope.

Download	Contents
Complete JSON (OUTPUT)	Full report, source rows, scope, rules and evidence.
evidence.csv	Flat overlap pairs, identifiers, UTC intervals, severity and source references.
findings.csv	Duplicate identity and coverage findings.
report.html	Standalone escaped report with all source rows. Download and open locally.

You can also download the dataset using Apify's export formats such as JSON, CSV or Excel. For this nested report, the dedicated flat CSV is the clearest spreadsheet view. CSV cells beginning with spreadsheet formula prefixes are neutralized; complete JSON preserves the original identifiers.

Cost, limits and recovery

The price is $0.25 per completed report, including platform usage. There is one report-completed event and no startup or per-dataset-item fee. Invalid input, excessive pair density and oversized exports fail before that report event. One new run of the same input is a new billable report.

Inputs are limited to 4 MB of serialized JSON and 2,000 booking rows. The report emits at most 10,000 overlap evidence pairs. Full JSON must be below 8 MB and each export below 9 MB. These limits apply together: repeated source evidence or long identifiers can reach an export size limit below 10,000 pairs. Split dense snapshots by a useful resource or time scope; avoid losing crossing buffers when splitting time windows. The default runtime is 1,024 MB and 180 seconds.

All exports are prepared and size-checked before publishing the dataset item and charging its event. An interrupted run can leave partial export files. Resuming the same run rewrites them and verifies the saved report and input before reuse; it keeps one dataset item and at most one completed-report charge. A run interrupted between saving the dataset and confirming the event may need recovery before it is considered complete. The separate downloads are not an atomic transaction.

Scope, privacy and support

This report is finite exported schedule evidence for human review. It does not prevent live double bookings, write to calendars, optimize assignments, analyze staffing or legality, or guarantee a reservation. A no_overlaps_in_declared_scope result applies only to the declared complete snapshot. Use your booking system to resolve findings and enforce reservations.

Use opaque IDs and only data you are authorized to process. Do not include names, contact details or attendee information. Inputs and results remain in Apify cloud run storage according to your account's retention settings; the Actor does not delete them. It accepts no remote URLs, FTP, credentials or proxy settings. For validation errors, check field names, explicit timestamp offsets, scope membership and CSV mapping first. Use the Issues tab for feedback and the API tab for programmatic access.