Who Everflow is
Everflow is a partner marketing platform founded in May 2016, with offices in Mountain View in California, in Montréal and in Amsterdam. It describes itself as a profitable, bootstrapped company. A business uses it to run its own partner programme: each partner gets a tracking link to an offer, each click on that link gets a transaction ID, and a conversion reported against that ID is credited to the partner who sent the click. Every offer has one base conversion event and as many additional events as the funnel needs, each with its own payout, so an install, a sign-up and a first payment can be told apart.
Conversions reach Everflow by server-to-server postback, a web request sent from one server to another, by its JavaScript SDK on web pages, or through its API, which has Network, Affiliate, Advertiser and Marketplace parts. For apps it has integration guides for the mobile measurement partners AppsFlyer, Adjust, Branch, Singular and Kochava. Postback Controls approve, reject or hold conversions by rule, IPQualityScore and Anura connect for fraud screening, and Everflow Pay pays partners from the invoices Everflow generates. Everflow is built on Google Cloud Platform, has completed a SOC 2 Type II audit, and hosts some accounts on EU servers only. It credits partners on what a server reports, not on what a browser saw, which is why it is one of the affiliate and partner programme connectors of our Rewards & referrals module.
What it does in your platform
Rewards & referrals
Tracks the partners who send you customers: affiliate sites, creators and media buyers each get an Everflow tracking link, and every click gets a transaction ID. The platform's server reports what really happened against that ID, a sign-up as one event and a first card payment as the paid one, and rejects the conversion if the payment is refunded. The reward here is a payout to a partner, recorded and invoiced in Everflow. It is not a credit in your ledger, and no customer is paid through it.
How the connection works
The platform's server reports each event to Everflow as a server-to-server postback: a GET request to your Everflow tracking domain with your network ID (nid), the click's transaction_id and an event_id. It reads and changes conversions through Everflow's Network API, with a key sent in the X-Eflow-API-Key header. The key and the postback's verification token never leave the server, and no conversion is taken from a browser pixel.
A partner shares a link
Your team adds a partner in Everflow, say a comparison site, a creator or a media buyer, and gives them a tracking link to your offer. When a visitor taps it, Everflow records the click, gives it a transaction ID, a 32-character code, and sends the visitor on to your landing page with the ID in the address, as _ef_transaction_id unless the offer renames it.
The platform keeps the ID
The platform stores the transaction ID with the sign-up, because Everflow expects the advertiser to hold it and purges click details after 90 days without a conversion. For an app install, the link runs through your attribution connector from the Analytics & monitoring module, AppsFlyer, Adjust, Branch or Singular, each of which Everflow has an integration guide for, and that tool reports the install back to Everflow. A link that opens the app directly can be recorded by the server itself through Everflow's /clk endpoint, which answers with the transaction ID.
The sign-up is reported, unpaid
When the visitor opens an account, the server fires a postback with the sign-up's event_id. That event is set up with no payout, so the partner sees the progress in their reports and earns nothing yet. The postback names no one: it carries the transaction ID, the event and a random reference as order_id, and never a name, an email address or an account number.
KYC and a first card payment
The platform decides when the partner has earned, from its own records: here, the customer passed KYC and a first card payment settled within 30 days. Only then does the server fire the paid event's postback. It always names the event, because Everflow files a postback without an event_id under the base event and raises no error, and by default Everflow rejects a second conversion for the same click and event as a duplicate.
The conversion is approved
Your team chooses in Everflow how a conversion becomes payable: at once, after manual approval, or after a holding period set in a Postback Control, at the end of which Everflow approves it automatically. A conversion On Hold shows to the partner but is not payable. Everflow's webhooks announce a conversion when it is registered, not when its status changes, so the platform reads each status (approved, pending, rejected or invalid) through the Network API and shows it in the backoffice. Approved conversions go onto the partner's invoice when the billing period closes. That payout is a record in Everflow, not a credit in your ledger.
A refund takes it back
If the payment is refunded or charged back, or the account is closed after a fraud review, the server sets the conversion to rejected through PATCH /networks/reporting/conversions, or fires Everflow's reversal postback with the transaction ID and the event. A rejected conversion is not paid. If the partner was already paid, Everflow shows it on their invoice as a clawback. To lower a payout without cancelling it, the platform updates the conversion's payout through the API instead.
Next to other providers
Everflow is told only what a partner's payout depends on: a click, an event, a status. The facts behind each event come from the platform: KYC / AML confirms the person, Card issuing and the Ledger confirm the settled payment, and Fraud & risk checks the identity and the device against the accounts you already hold, whatever Everflow's own controls, such as its click-to-conversion time limits, or its IPQualityScore and Anura integrations flag at the click. App installs are matched to links by the attribution connectors of Analytics & monitoring. A partner's payout stays in Everflow. A reward for a customer is a different thing: a refer-a-friend bonus runs through the module's referral connectors and is paid as a credit by the Ledger, and a gift card is delivered by Runa.
Everflow is one of the module's affiliate and partner programme connectors, next to impact.com, Awin and PartnerStack. Everflow suits a programme you recruit and run yourself, impact.com manages creators, affiliates and customer referrals on one platform, Awin is an affiliate platform with its own large base of approved creators and affiliate partners, and PartnerStack is dedicated to B2B software, with a marketplace of partners. The qualifying rules, the link between each customer and the click that brought them, and the KYC and payment evidence live in the platform, so a move between them swaps a connector and leaves your apps and your records as they are. Offers, events, payout rules, Postback Controls and partner accounts are built in Everflow and would be set up again in the new tool. Partners would be invited again and given new links, and open invoices settled in Everflow first.
When Everflow fits best
A strong fit when
- You recruit and manage your own partners, affiliates, creators and media buyers alike, and want them tracked by server-to-server postback, not by a browser pixel.
- You pay on a milestone deep in the funnel, such as a first card payment after KYC, and want the install and the sign-up tracked as separate events on the way.
- You want conversions held for a set period before they become payable, so a refund or a closed account is rejected before the partner is paid.
Also worth a look
- impact.com, Awin or PartnerStack, the module's other affiliate and partner programme connectors.
- A partner platform your team already runs: its account becomes a connector too.
How we get you live
The contract
We help you get your Everflow account and contract in place, with its data processing addendum, which is part of Everflow's terms of service, and with Everflow Pay if you want partners paid from inside Everflow.
The data
Everflow hosts some accounts on EU servers only, reached at api-eu.eflow.team, so we settle with Everflow where yours will sit before anything is built. With your team we set up the offer in Everflow: its events (install, sign-up, first card payment), the payout on each, any caps and the holding period. Those live in Everflow's dashboard. The conditions a customer must meet, and the countries and products the programme runs in, are set in the backoffice. Postbacks leave out the optional email and user_ip parameters, so Everflow logs the platform server's address against a conversion, not the customer's.
The keys
The Network API key goes into your platform's secrets. Everflow shows it only once, and each key has its own permission scopes, so the platform's key is limited to what the platform calls. The advertiser's verification token is switched on, so Everflow turns away any postback without it as an invalid verification token, and the token stays on the server too. Partners see their clicks, conversions and invoices in their own Everflow login and hold no key to your platform.
A full test run
Everflow's testing guide describes no separate sandbox, so the test runs in your account before any partner is invited. We create an internal test partner, as Everflow suggests, open its tracking link in a private window and take a test customer through the platform's own test environment, from sign-up to a refunded payment. Your team checks each step in Everflow's Conversions and Advertiser Postbacks reports, and that the rejected conversion never reaches the test partner's invoice.
