What actually happens, in plain words.
Meerkly is the network behind UnblockingAPI: devices that load public web pages for its customers, using a slice of a connection that was sitting idle anyway. Here is the whole of it, from the moment a customer asks to the moment you get paid — written for anyone, not just for developers.
From switched on to paid, in five steps.
- Run MeerklyOn a phone, a computer or a server you leave on anyway.
- Your device joins the networkIt holds one outgoing connection to our gateway and waits. Nothing is opened for anyone to connect in.
- A customer asks UnblockingAPIA business sends UnblockingAPI a request for a publicly accessible web page.
- An eligible device fetches itIf your connection and location match the request, your device may be the one that loads it.
- You earn for the work donePaid per GB your connection actually carries. No request, no pay: earnings follow demand.
What happens when your device is asked for something.
A customer asks UnblockingAPI for a page
Businesses check prices, search results, listings and their own adverts as they appear in other places. From a data-centre connection those public pages often look different or refuse to load, so they ask UnblockingAPI to fetch them from an ordinary connection. The customer talks to UnblockingAPI, never to a device.
The network picks an eligible device
One that is online and matches the request, and yours is one of many. All that gets sent to the device is the address of the page. No files, no programs, nothing that stays behind. If no request matches a device, it simply waits.
The device fetches it and passes it straight back
It goes and gets the page the same way your own browser would, and hands it back through us. It does not open it, read it or keep it. Think of a courier carrying a sealed envelope: it goes through your hands, and you never see inside.
You are paid for what went through
We measure, on our side, what your connection carries for it as it moves — the device is never asked how much it did, so there is nothing to get wrong or argue about. No request, no pay: being online makes a device eligible, and demand decides how often it is picked. Your own browsing is not part of any of this.
Loading public web pages for UnblockingAPI’s customers.
That is the only work Meerkly sends. Nobody buys access to your connection directly, and nobody can reach your device.
Every request comes through UnblockingAPI
Meerkly is the supply side of UnblockingAPI, a service businesses use to load publicly accessible pages (prices, search results, listings) as they appear from an ordinary connection. Its customers send requests to UnblockingAPI, never to you.
Not a proxy for sale
We do not sell raw proxy access, and there is no way to buy your IP address and connect through it. Your device only ever dials out to our gateway. It opens no port, so there is nothing for anyone to connect to.
Public websites only
Your device refuses anything that is not on the public internet, so your router, your printer and the rest of your home network stay out of reach. Email is blocked before a request is ever handed out.
Watched, and acted on
Every request is logged with the customer account behind it. We monitor how the network is used and block abusive activity when we find it. Nobody can vet every web address in advance, so we do not claim to. We keep watch and act instead.
The same thing, precisely.
Nothing new here — this is the paragraph above with the protocol names left in. Skip it happily if it is not your sort of thing.
An exit node holds a single outbound QUIC connection to the gateway, however much traffic flows over it. Nothing listens for inbound connections, so it works behind NAT and opens no hole in anyone's network.
The gateway's customer side accepts only credentials we issue, each verified against the dashboard, and those go to UnblockingAPI. There is no self-serve sign-up for proxy access, and no inbound path to an exit at all.
No config file, no cache and no identity of its own. Whatever the host application does not persist for it, it does not persist. A device id, if there is one, is minted and kept by the host.
The exit resolves the target itself, rejects anything that is not a routable public address — loopback, RFC 1918, link-local, CGNAT, unique-local — and then connects to the address it validated, never re-resolving the name, so DNS rebinding cannot slip through.
The QUIC connection's own counters measure the tunnel leg as it moves — UDP payload plus IP/UDP headers, both directions. A wrapper on the gateway's stream counts the site-side payload, to which a stated 4% header allowance is added. Both are flushed to a durable stream. Nothing that decides money is ever self-reported by a client.
Depends which side you are on.
You are the last step — on a phone, a laptop or a server, it is the same. Your device fetches the page, we count the data on our side as it moves, and you are paid for it by the gigabyte. Your own browsing is never part of it.
Let your phone pay youIf you are shipping an appYour users' devices are the last step, and your publisher id is what says the bytes are yours. Your app carries the traffic; it is never the destination, and nothing about what your users do inside it is involved.
Monetise without adsNow you know what it does. See what it pays.
Create an account and point a device at it, or take a publisher id and run the SDK on your own machine first.