Marketplaces for small paid tasks have a reputation problem, and it is deserved. The category is full of platforms whose actual product is fake engagement sold with a thin marketplace wrapper. Any serious buyer's legal team knows this, and so does any investor who has looked at the category before.
This page exists so that the review is short. It documents what is enforced in code rather than promised in copy, and it names the gaps rather than waiting for someone to find them.
The specific mechanisms below are set out in more detail in proof standards and country and language targeting. The refusal list below follows from the verification model described in how RentHuman works. Why evidence rather than reputation is the basis for any of this is argued in proof beats reputation.
The line we will not cross
Campaign moderation happens before funding, not after complaints. An administrator reviews both the public brief and the private instructions, because the interesting part is usually in the private half. Campaigns are rejected when they require any of the following:
This costs revenue. It is also the reason a campaign here can go through a brand's legal review at all, and the reason payment processing does not sit permanently one complaint away from termination. Buyers commissioning creator content run into that line least often, because the brand posts the work as its own advertising.
The underlying principle is simpler than the rule list.
A reader must be able to tell that money changed hands.
Disclosed creator content posted by a brand on its own channel is advertising and needs no pretence. A paid five-star review from an apparently ordinary customer is the one arrangement built on the reader not knowing, which is why it is prohibited everywhere and why we will not process it.
Controls in the product
Confidentiality by default. Private instructions and private proof requirements are withheld from every public response. They unlock only for a worker holding an active authorised reservation on that specific task. A worker cannot browse other people's briefs, and a campaign's sensitive detail is never sitting in a public listing waiting to be scraped.
Proof handling. Submissions may be a written note, an HTTPS link, or private files within these limits:
Every submission takes one of those shapes. Files are signature-checked on arrival and quarantined. That review clock does not begin until an administrator has cleared them, so nobody is timed against unreviewed media. Private object keys are never returned through public or ordinary dashboard APIs; media streams through an authorised endpoint with no-store and nosniff.
Bounded corrections. One correction request per submission. It pauses automatic approval and gives the worker 24 hours. This is deliberately not open-ended, because unlimited revision requests are how marketplaces quietly extract unpaid work.
Appeals with a real decision. Rejection opens a 72-hour worker appeal. An administrator upholds or overturns it. Overturned rejections settle through the same retry-safe path as ordinary approvals, so a reversal cannot double-pay or half-pay.
Automatic approval. Unreviewed work approves after 48 hours. A poster who goes quiet cannot hold a worker's payment indefinitely, which is the single most common failure mode in this category.
Eligibility checked before reservation, not after delivery. Country, city, language, social-profile, content-work, device and optional demographic requirements are enforced at the point a worker tries to reserve. The final database write must still match the exact normalized worker profile and campaign eligibility that passed the preflight check, so a concurrent edit in another tab fails closed instead of creating work from stale answers. A mis-targeted campaign surfaces immediately rather than as thirty unusable submissions at review time.
Worker integrity confirmed before matching. A worker cannot enter matching, discovery, invitations or reservations until they explicitly confirm that they are an adult, will follow the rules of every platform they use, will disclose paid participation when required, will not submit false reviews or impersonate another person, and will never surrender control of an account to a poster. These confirmations are private timestamped eligibility records, not a banner that can be skipped.
Policy changes pause new work without stranding existing obligations. A worker accepts the exact published Terms and Privacy Notice versions for the worker role. If either version changes, the worker disappears from new-task matching and poster discovery and cannot receive another invitation or reserve another task until accepting the current pair. The invitation and reservation database writes repeat that exact-version check. Existing assignments, confidential task access, appeals, earnings and payouts remain available, so a document update cannot take away access needed to finish work or receive money already earned.
Availability requires an explicit choice. First-time onboarding asks separately whether the worker wants to enter new-task matching and whether matching posters may send direct invitations. Both questions require a yes or no answer and are persisted in the same activation batch as the capability profile. A new worker is therefore not made discoverable merely because a database column had a default value.
Account changes are abuse-limited without using email or IP addresses. Worker activation and profile-update attempts pass through a Cloudflare Workers rate-limit binding keyed by a route-specific SHA-256 digest of the internal authenticated account identity. A denied request returns HTTP 429 with a one-minute retry hint before any profile write. If the binding itself is unavailable, these sensitive mutations fail closed with HTTP 503. Edge-local counters are an operational abuse brake, not an eligibility, payment, or correctness boundary.
Authentication has separate distributed limits. In production, ordinary authentication traffic, sign-in/signup and credential changes, and verification/password-recovery email requests use separate Cloudflare rate-limit tiers. Better Auth accepts the client address only from Cloudflare's edge-provided header, normalizes IPv6 networks, and passes only a SHA-256 digest of the client-and-route key to the limiter. Denied requests return HTTP 429 with a standard retry hint before password verification or email delivery. This protects shared authentication infrastructure without storing the raw client address in the rate-limit service.
Workers can take their onboarding profile with them. The signed-in account page provides a JSON download containing the identity metadata and private worker answers RentHuman stores for matching, including owned social platforms, accepted video/content work, available devices, optional targeting details, availability choices, and each exact worker-requirement contract the worker accepted. Passwords, OAuth tokens, sessions, recovery secrets, payout destinations, provider credentials, proof, campaign/financial records, and other users' information are excluded. A real authenticated session is always required; local development identity headers cannot retrieve the export.
Account closure stops new activity without destroying unsettled evidence. A signed-in owner can submit an auditable closure request only after typing an exact confirmation phrase. The same transaction pauses worker matching and direct invitations, pauses open poster campaigns, cancels their pending invitations, and revokes active AI-agent tokens. Existing assignments, appeals, earnings, and payout access remain available until they are settled. Cancelling a pending request does not silently reopen marketplace activity or restore revoked credentials. Final deletion is retention-aware and reviewed rather than presented as an instant erase button.
Closure review is separated from deletion authority. Marketplace operations receives an oldest-first queue with aggregate open-assignment, appeal, and payout counts. The queue returns an internal account ID and a fixed set of role/availability flags, not email, profile answers, campaign content, proof, payout destinations, or arbitrary stored request context. An administrator can claim a request for review or reject it with a recorded reason. Erasure becomes available only after an eligible assessment under the currently configured policy and requires a separate exact typed confirmation.
Retention eligibility is versioned and fail-closed. Operations can record a fresh assessment of live assignments, appeals, payouts, worker balances, unsettled campaigns, funding reconciliation, and proof objects. The assessment is never eligible without an explicitly configured approved policy version, and the missing version is a production-readiness failure. Eligibility means only that live obligations are clear under that policy; it does not claim that identity data or proof objects have already been erased.
Erasure is staged, retry-safe and evidence-preserving. Private proof objects are removed from storage in bounded batches before their database rows disappear. Only then does one database transition remove authentication, sessions, profile and payout-destination data, private match snapshots, invitations, notifications and agent credentials, clear proof links/notes, and replace the application identity with a non-deliverable pseudonym. Completed-work, financial, dispute and moderation rows keep that pseudonymous internal ID. The job checks obligations and policy again immediately before anonymization, cannot race a rejection, and is safe to retry after partial object cleanup.
Country targeting uses one validated catalogue. Workers choose a localized country name rather than typing an arbitrary code. First-time onboarding, later profile edits, campaign country targeting, and city-country pairs all use the same ISO-based server contract, with operational Kosovo support. Invented and reserved values are rejected. A saved home country is still a matching preference, not proof of presence: targeted reservation access independently checks Cloudflare's request geography when the edge supplies it.
Separation of authority for AI agents. Posters can issue scoped, revocable tokens so an agent drafts campaigns on their behalf. The raw token is shown once and only its SHA-256 hash is stored. Each credential carries a per-campaign allocation limit and a monthly draft budget enforced at the database write boundary. An agent can dry-run and create a private draft. It cannot moderate, fund, publish, invite workers, review proof, reach worker identities, or start a payout, and it can read only the campaigns it created rather than everything the poster owns. Every agent draft lands in front of a human.
Money controls
Funding is calculated server-side as reward per spot multiplied by total spots, so the client cannot propose its own total. A browser redirect never settles money; only a timestamped, HMAC-verified webhook with a matching campaign, poster, amount and currency does.
Bank-transfer funding uses an exact amount and a unique reference that an administrator reconciles against the statement. The poster cannot self-confirm payment, and one provider transaction reference cannot fund two campaigns. An awaiting transfer blocks other funding routes on the same campaign, so a campaign cannot be double-funded through two paths.
Approval writes a balanced append-only ledger transaction: campaign reserve debited, worker available balance credited. Withdrawal requests require idempotency keys and move funds from available to pending atomically. The worker-facing account of the same mechanism is how payouts work.
Payouts are currently reviewed rather than automatic. An administrator batches requests, exports privately, executes the transfers externally, then reconciles paid and failed outcomes atomically. That is slower than an instant-payout promise and it is honest about what a young platform can guarantee. Direct execution can later replace only the external transfer step without changing the ledger or the payout lifecycle.
Data handling
Worker history and marketplace feeds use explicit safe projections rather than returning full campaign or proof records, so an API response cannot leak a field nobody intended to expose.
Posters see the proof they asked for and the approval state. They do not see a worker's account data, contact details or payout destination. Payout destinations are entered by the worker in a private area, returned masked to worker-facing APIs, and visible in full only to payout operations. A new or changed destination returns to pending and must be reviewed before it can be used, and active payouts lock destination changes.
Temporary identity headers used in development are localhost-only and are ignored whenever a real session exists.
Worker onboarding promises have their own versioned acceptance record. When a worker confirms adult eligibility, platform integrity and account safety, the exact contract text and acceptance time are inserted in the same database batch that enables matching. One worker can have only one record for a requirements version, repeated requests cannot replace it, and the database rejects updates. If the wording changes, the requirements version changes and workers must explicitly accept the new contract before matching resumes.
Workers can also pause all new work without deleting the history needed to finish assignments or receive money already earned. A paused profile is removed from personalized matching and poster discovery and cannot receive or reserve new work. Existing reservations, confidential task access, invitations, earnings and payout operations remain available. The invitation and reservation writes recheck availability at the database boundary, so a request that started just before the worker paused cannot slip through after the pause was committed.
Worker eligibility edits use optimistic concurrency. The dashboard sends the exact profile update token it loaded, the database advances that token monotonically, and a stale tab receives a conflict plus an explicit reload action. An older copy of the form therefore cannot silently replace newer social-profile, content-work, device, demographic, or availability answers.
When a worker does reserve a spot, the same database transaction writes a private immutable snapshot of the eligibility facts that matched at that moment: normalized profile attributes, capability and requirements versions, campaign eligibility, profile update time, and request country/city when Cloudflare supplies them. No IP address is stored. The snapshot is not exposed to the marketplace, poster directory, task page, invitation feed or ordinary worker APIs, and later profile edits cannot rewrite it.
What an investor should read here
The controls above are the answer to the operational-risk question. Three more things belong in a diligence pack and are easier to state plainly than to be asked for.
Worker rewards. Posters fund the full worker reward allocation before publication. The amount shown on a task credits to the worker balance on approval; RentHuman does not reduce that listed reward. Any future poster-side pricing must be disclosed separately rather than hidden inside the worker amount.
The refusal policy is a moat, not a cost
Competitors in this category who sell engagement have a ceiling: they cannot sign an enterprise client whose legal team reads the terms, and their payment processing is contingent on nobody complaining loudly. Turning that revenue away is what makes an enterprise pipeline possible at all.
The real risk is liquidity, not compliance
Posters and workers have to be acquired at a matched rate. A marketplace with campaigns and no workers fails exactly as fast as one with workers and no campaigns. No control on this page addresses that, and anyone evaluating the business should weight it above everything above.
How a worker is protected
Buyer-side controls are only half of a marketplace's integrity, and the worker-side terms are what determine whether there is a supply to sell.
The money exists before the work does
A campaign cannot publish unfunded. A worker reserving a spot is reserving against committed funds rather than against a stranger's intention to pay.
The clock is bounded and starts fairly
Review runs 48 hours, and it begins only once submitted files have cleared safety review, so a worker is never timed against media nobody has looked at. Unreviewed work approves automatically.
Revisions are capped
One correction request, with 24 hours to respond. A poster cannot iterate indefinitely against a fixed payment.
Rejection is reviewable
A 72-hour appeal decided by an administrator, not by the poster who rejected the work. This is the term most platforms in this category omit, and its absence is what makes a marketplace unsafe to work on regardless of how good the rates look.
Reservations release cleanly
A worker can release an unused reservation, which restores campaign capacity and removes unattached private uploads rather than leaving orphaned files.
Payout destinations are controlled by the worker
And visible in full only to payout operations, with any change returning to pending for review before use.
The clock and its branches are the same ones a poster works against.
Questions we expect and the short answers
"Can you prove a submission came from the country it claims?" Eligibility is checked against a worker's verified profile before reservation. That is a strong control, not a perfect one, and we would rather characterise it accurately than overstate it.
These are not courtesies. A marketplace that rejects arbitrarily loses its pool, and a buyer's results depend entirely on that pool being willing to take the next campaign, whether the brief is a single creator booking or a distributed sample across forty people.
"What happens to our campaign data if we stop using the platform?" Private instructions and proof remain in private storage under the same access rules. Nothing sensitive moves to a public surface at any point in a campaign's lifecycle, including after completion.
"Who at your end can see our brief?" Administrators reviewing the campaign at moderation, and the workers holding reservations on it. Nobody else, and no public response exposes the private half.
"What is your incident process?" Quarantine holds unreviewed media out of a poster's reach by default, which contains the most likely class of incident before it reaches anyone. Beyond that, we would answer this against your own checklist rather than claim a maturity we have not yet exercised at volume.
What we do not claim
There are no customer logos on this site that are not customers, no review scores we generated, and no marketplace volume figures we cannot evidence. Public pages use clearly labelled examples; real jobs appear only inside the dashboard behind authentication.
Open items
Production launch has not happened yet. Transactional email must ship before password registration is enabled. The reviewed funding and payout paths need real-money validation at small amounts before wider use. Google OAuth, the canonical hostname and webhook behaviour need validating against the final production domain.
Proof moderation and disputes create genuine operational workload, and that workload scales with volume rather than staying flat. Marketplace liquidity remains the core business risk and is not solved by any control described here.
We would rather you read that on this page than discover it in diligence.
The same boundary applies to any task involving regulated data, security testing or professional advice: those categories belong with a qualified specialist under the right legal protocol, not an open distributed pool.