An EA may download API data on demo yet receive no equivalent responses in the tester. That need not indicate a server outage. Check function availability in the testing environment before examining the archive. Downloading today's value and assigning it to earlier decisions creates a different test. The model below replays explicit versions, distinguishes revisions from unavailable data and makes no external API connection.

Why is a working WebRequest insufficient for backtesting?

MQL5 documentation states that WebRequest cannot execute in Strategy Tester. Adding an endpoint to the terminal's permitted URLs does not change this restriction. Distinguish an unavailable testing function from a network problem, failed authorisation or the response received during ordinary EA operation.

Suppose a rule needs an external economic observation. Do not replace a failed request with zero: zero may be a legitimate value, whereas failure means the input is unavailable. Replacing WebRequest with a file is also insufficient if that file contains revisions unknown at the time of the decision.

Define the required observation, version, value and availability time before connecting signal logic directly to HTTP. Our EA guide separates data, decisions and execution; this article develops the data layer. A different adapter should not silently change what the information means or how missing input affects the strategy.

How do you separate online and offline adapters?

The online adapter handles a provider response. The testing adapter selects a preserved record available at the decision time. Both deliver the same kind of result to the decision logic: a valid value, explicit unavailability or an error. This is our proposed code organisation, not a complete trading robot or a promise of compatibility with every API.

Preserve raw responses separately from test-ready records. Record the source, schema version, retrieval time and evidence for availability. The period an observation describes is not the time it became known. If you know only a vintage date, do not invent a precise release hour. A daily archive cannot by itself establish availability within that day.

FRED describes real-time periods distinguishing information known now from information known previously. This is an example of versioned data, not a universal FX API. A vintage date does not automatically supply an exact UTC publication timestamp. Establish the particular provider's chronology before preparing intraday test input from a date-only record.

In MQL5, FileOpen uses a defined file area, including during testing. A relative path need not point to the ordinary terminal folder. Check opening and reading success. Missing input should produce recognised unavailability, not an empty table treated as complete history.

Which version can an earlier decision use?

Own history of three responses

Assume the fictional observation GDP-model on 1 October 2026. These are not GDP releases or records from an actual endpoint. Every timestamp is UTC. availableAt defines when our model can access the record; it does not determine an order's execution time.

Own model versions: a later record is not earlier knowledge
availableAtrevisionvalue
2026-10-01T12:00:00Zinitial"1.0"
2026-10-01T13:00:00Zrevised"1.4"
2026-10-01T14:00:00Zunavailablenull

At 12:30 the latest eligible value is 1.0. At 13:30 it is 1.4. At 14:30 the newest eligible record has null, so the result is unavailable. Our model neither falls back to the older 1.4 nor converts the absence into zero.

The version available then, not today

The version available then, not todayFictional GDP-model: 1.0 becomes available at 12:00 UTC, revision 1.4 at 13:00, null at 14:00. Decisions at 12:30, 13:30 and 14:30 select 1.0, 1.4 and unavailable. Missing is not zero.The version available then, not today12:00 UTCinitialvalue: "1.0"12:30 → 1.013:00 UTCrevisedvalue: "1.4"13:30 → 1.414:00 UTCunavailablevalue: null14:30 → missingOwn events on 1 October 2026 • all times UTC
Conclusion: a revision does not change an earlier decision’s knowledge. In our variant null blocks evaluating a new signal; no zero or older value is substituted.

A fictional rule requiring a value above 1.2 would be false at 12:30. Substituting the later 1.4 would reverse that decision even if price data remained identical. This examines information availability, not strategy profitability. The tool selects a record; it does not calculate a trading signal or return.

If a strategy should retain the last known value when new information is unavailable, design that as a separate policy. State the permitted age and reason for using the older record before evaluating results. Our explicit-null variant deliberately does not implement that fallback. Do not add it after seeing a more attractive result and present the rerun as unchanged.

What can you inspect in the local replayer?

Paste a JSON object containing numeric version 1 and an events array. Every event has availableAt, observation, value and revision. availableAt requires YYYY-MM-DDTHH:mm:ssZ without fractional seconds or other offsets. observation and revision are strings. value is decimal-point numerical text or null, without conversion to Number. Limits: 1–200 events and 64 KiB JSON; observation and value up to 128 characters, revision up to 64.

Replay information available at decision time

Our teaching example runs locally in your browser: it does not connect to an account or API, send your entries or save them persistently. Do not enter passwords or personal details.

Format and model limits

version: 1; events: 1–200 objects with exactly the fields availableAt, observation, value, revision. availableAt: YYYY-MM-DDTHH:mm:ssZ. observation: string up to 128 characters; revision: string up to 64 characters; value: decimal-point numeric string (up to 128 characters), or null. Missing is not zero.

The last version whose availableAt is no later than decision time is selected. Two entries sharing observation and availableAt are ambiguous and block analysis. JSON limits: 64 KiB, 8 levels, 2,000 values. Times are declarations: the page cannot verify the actual release time.

Enter decisionAt separately using the same UTC format. The model selects an observation's latest version whose availableAt does not exceed that time. Before its first record, no value is available. Two records for the same observation and availability time are ambiguous and rejected, rather than resolved by paste order. The revision label is not a numerical chronological counter.

This exercise works locally on pasted events without downloading releases or using API credentials. It does not verify provider timestamps. Valid JSON is not proof of a genuine archive. If you guess the dates or label all subsequent revisions with the initial release time, a correct selection algorithm reproduces incorrect assumptions. Preserve provenance documentation for any actual dataset used in research.

Tester documentation distinguishes agents' files and environments from the terminal. Use a fixed dataset copy for parallel runs rather than overwriting it with a live response during the study. Record the actual preserved dataset in your run manifest, not just the endpoint name.

Our Python backtesting guide develops time-based joins; the calendar guide addresses release revisions. Data replay does not automatically replay execution: Bid/Ask prices, charges, quantity and server responses remain separate components. Begin by comparing a few decisions without placing trades, before attributing a result difference to the strategy.

What should you do before judging this EA's results?

  1. State the data contract and separate online from offline adapters. Preserve raw responses, observation definitions and evidence for availability. Mark missing historical versions as a limitation instead of assigning today's endpoint value to an earlier date and treating it as archived knowledge.
  2. Trace one fictional observation before its initial version, between release and revision, and after explicit unavailability. Compare selected records with the table. Test the exact availability boundary and conflicting timestamps before using the algorithm for a larger study.
  3. In the tester, confirm the intended file is read and missing data is recognised. Store the dataset version with its report. After explaining discrepancies, check signals, execution and costs separately. Correct replay of inputs does not establish future strategy profitability.