--- title: "Onsefy Integration" description: "Connect AI agents to Onsefy, an API-first fraud detection and user validation platform. Agents validate a user at signup, and apply the same check again at any high-value action a flow reaches." url: https://flowrunner.ai/integrations/onsefy date_modified: 2026-08-11T09:36:14-07:00 --- # Onsefy [Identity & Security](https://flowrunner.ai/integrations/category/identity-security) Connect AI agents to Onsefy, an API-first fraud detection and user validation platform. Agents validate a user at signup, and apply the same check again at any high-value action a flow reaches. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 1 action · Custom auth · available [Onsefy website](https://onsefy.com/) · [Platform Documentation](https://docs.onsefy.com/) · Capability data verified 2026-08-06 1. A signup form submits and the flow holds the record before it is written anywhere 2. Agent collects the email or phone, the full name, the originating IP, and the user agent string 3. Agent confirms all four values came from the real request rather than a default or placeholder 4. Agent runs Validate User and reads risk\_level, risk\_score, score\_confidence, and the matched risk\_patterns 5. Agent compares the returned confidence against the floor the policy sets for automatic action 6. Risk owner receives held signups with the per field breakdown and the transaction\_id 7. Any rejection on substituted inputs or low confidence is confirmed by a person before the signup is refused ## What This Integration Enables One action, and the design claim behind it is the reason to use it. Onsefy scores a signup before it reaches your database rather than after, which is a meaningfully different job from cleaning up records you have already provisioned, emailed, and counted. Validate User takes an email or a phone number, plus the originating IP address, the full name, and the browser or device user agent, and assesses them together as one request rather than as five independent reputation lookups. The response carries a summary with risk\_level, where 0 is legit, 1 is suspicious, and 2 is fraud, along with verify\_label, a risk\_score from 0 to 10, score\_confidence, and the engine that produced it. Alongside the summary it returns the matched risk\_patterns, a per field parameters breakdown showing which of the supplied values contributed, a transaction\_id, and a timestamp. That breakdown is what makes a hold explainable to the customer and to whoever has to answer them. Three things about this connector are worth planning around rather than finding out. Either email or phone must be supplied, but ip, name, and user\_agent are all required, which means a signup path that does not genuinely capture all three cannot be scored honestly without substituting values. VPN Check, which runs proxy and VPN detection, and Advanced, which enables extended checks that may add latency, are both available on paid plans only, so a flow that sets them on a free tier key does not get those checks and does not get told it did not. The API Tier configuration selects which host the requests go to, free-api.onsefy.com or api.onsefy.com, and it has to match the tier your credentials belong to. The connector exposes no triggers: nothing in Onsefy starts a FlowRunner flow and there is no event stream, so the call is made by whichever system receives the signup, at the moment it receives it. ### Without FlowRunner **Fraud found after the record exists**: Bad signups are cleaned out of the database later, once they have already done something **Signals checked one at a time**: Email reputation, IP, and name are each looked at separately and never together **Rejections with nothing behind them**: A signup is refused and support has no per field detail to answer the customer with ### With FlowRunner **Assessment before the write**: Validate User runs while the record is still held, not after it has been provisioned **One combined assessment**: Email, phone, IP, name, and user agent are scored together with the matched patterns returned **Rejections that can be explained**: The parameters breakdown, risk\_patterns, and transaction\_id are recorded with every held signup ## Use Case Scenarios ### Scoring a Signup Before Provisioning A signup form submits and the flow holds the record rather than writing it. The agent takes the email address, the full name, the originating IP, and the user agent captured by the form, and runs Validate User. A risk\_level of 0 provisions the account normally and nothing about the check is visible to the user. A risk\_level of 2 with high confidence and several matched risk\_patterns holds the signup and posts it to the risk queue with the per field breakdown attached. A risk\_level of 1 is treated as what it is, an unresolved case, and routes to a step that asks for one additional proof rather than either welcoming or refusing on a middle answer. ### Enriching a Trial Abuse Investigation A product with a generous free trial is seeing repeat abuse. Rather than tightening the rules for everyone, the agent runs Validate User on new trial signups and records the transaction\_id, matched risk\_patterns, and parameters breakdown against each account. When abuse is confirmed weeks later, the team can look back at exactly what the assessment said at signup and which fields contributed, which turns a hunch about the pattern into something readable. The output feeds a rule change that a person makes deliberately, rather than a threshold that drifts. ### Gating a High Value Action Rather Than the Front Door Some products cannot afford friction at signup at all. Instead of scoring at registration, the flow scores at the first action that costs real money: a payout request, a bulk send, a referral claim. The agent runs Validate User with the values captured at that moment, including the current IP and user agent rather than the ones from the original signup, and holds the action for review when the assessment comes back suspicious or fraud. The front door stays open. The expensive door has a check on it, and the check has a person behind it. ## Human-in-Loop Highlight The gate here is defined by an action that does not exist. Onsefy has exactly one operation, Validate User, and there is no companion for reporting a wrong verdict, no reversal, and no appeal path in the connector. Refusing a real customer's signup is therefore final in a way that a spam filter's is not: they do not write in, they do not try again, and nothing in the API lets you tell the engine it got one wrong. That asymmetry, cheap to hold and irreversible to refuse, is where the pause belongs. It matters most in the specific case the API's own requirements create. Because ip, name, and user\_agent are all mandatory, a server side signup, a data backfill, or an app that does not capture a user agent forces the flow to substitute values, and the response comes back in exactly the same shape as one computed from real signals, with only score\_confidence hinting at the difference. So the agent will not refuse anyone on substituted inputs or on a confidence below the policy floor. It holds the signup instead and posts to the risk owner: "Held signup \[name\] at \[email\]. risk\_level \[n\], risk\_score \[n\], score\_confidence \[n percent\]. Matched patterns: \[list\]. Fields supplied from the real request: \[list\]. Fields substituted: \[list\]. Reject, approve, or request one more proof?" Clean assessments provision without anyone in the path, which is what makes the connector worth having. The refusal that cannot be taken back gets a name attached to it. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via email Human decides Agent resumes with decision ## Agent Capabilities 1 actions ### Validation 1 - **Validate User** Assesses a user signup for fraud and abuse risk using Onsefy's detection engine. Analyzes the supplied email, phone, IP address, full name, and user agent together and returns a risk level where 0 is legit, 1 is suspicious, and 2 is fraud, a numeric risk score from 0 to 10, a confidence percentage, the matched risk patterns, a per field breakdown, a transaction ID, and a timestamp. Either email or phone must be provided, and ip, name, and user\_agent are required. VPN Check runs proxy and VPN detection and Advanced enables extended checks, both on paid plans only. Because the connector offers no reversal or misdetection report, refusals on substituted inputs or low confidence are routed to a person. ## Frequently Asked Questions ### What can FlowRunner do with Onsefy? FlowRunner agents can run Validate User in Onsefy. ### Does connecting Onsefy to FlowRunner require OAuth? Onsefy uses a custom authentication method to connect to FlowRunner. ### Can Onsefy trigger a FlowRunner workflow automatically? Onsefy doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Onsefy?** This integration exposes Onsefy to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/onsefy. Site index: https://flowrunner.ai/llms.txt