Elfa takes the Auto API out of beta and adds crossover triggers

The Auto API leaves beta

Elfa's 16 May 2026 patch took its Auto API out of beta and added technical-indicator crossover conditions. It also described news and social triggers, Ask memory, mode-selection improvements and Telegram group access. The practical distinction in a crossover is that it describes a change from one state to another, rather than merely a value remaining above a threshold.

Why crossing a level differs from staying above it

Consider an invented indicator that records 19, then 21, then 22, with a comparison level of 20. A condition asking whether the indicator is above 20 is true at both of the last two observations. A condition asking whether it crossed from below 20 to above 20 describes the transition between the first and second observations. These instructions can therefore produce different alerts from exactly the same sequence.

That difference matters if a researcher wants to hear about a new event once, rather than receive repeated reminders about a continuing state. It does not establish that the event predicts a price move. The numbers in this example demonstrate the logic of a condition, without representing a real asset, an Elfa calculation or a profitable strategy. The intended behaviour should be written down before evaluating whether a returned alert is correct.

Decide what happens around the boundary

A second hypothetical sequence, 19, 21, 19 and 21, exposes another decision. The value crosses upward twice, with a downward move in between. A researcher may want both events, or may prefer one digest summarizing the repeated changes. Neither choice is automatically correct. It depends on the question being monitored and how frequently the underlying observations are taken.

A useful trial would include values equal to the threshold, missing observations and two conditions changing together. Ask how those cases are represented before connecting alerts to consequential actions. This is an acceptance-test suggestion, not a description of undocumented Elfa settings. Recording the observation time alongside the evaluation result helps distinguish an actual change in the data from a delayed or repeated notification.

An API workflow needs a readable event record

An API is a way for software to request or receive information without a person clicking through every step. For a research workflow, that can make it easier to store an event and pass it into a review queue. The resulting record should still be understandable to a human. An alert containing only a short identifier and a number is difficult to assess after the original context has disappeared.

A practical record might contain the question being monitored, the time of the observation, the source link and a plain-English explanation of the condition that became true. These are proposed fields for a team's own system, not claims about Elfa's response format. If a request is retried, the team should also be able to recognize whether it is processing a new event or the same event again. That avoids confusing delivery mechanics with changes in the underlying subject.

Conversation memory should preserve the question

Research often develops over several exchanges. A reader may first ask about a service, then narrow the question to a particular country, and finally ask about a deadline. The answer is useful only if those qualifications remain attached to the subject. A later question such as whether the offer is still open can otherwise lose the region or campaign that made it meaningful.

One way to evaluate a conversational tool is to create a short example with deliberate changes in scope. Ask about one market, switch to another, and then request a comparison. Review whether the final answer names both markets correctly and whether the supporting sources actually cover them. This does not assume perfect memory or any particular retention policy. It is a concrete way to check whether continuity improves the work rather than allowing an earlier assumption to go unnoticed.

Test a research notification before relying on it

For an initial trial, choose a condition whose outcome can be checked manually from a small set of observations. Compare the expected events with the received messages and investigate both omissions and duplicates. Then inspect whether each message contains enough context for someone else to review it. This turns an automation announcement into a useful evaluation exercise while keeping the historical release separate from any claim about today's account access or trading availability.