If you sell a small API on RapidAPI, the marketplace cut is only the first deduction. RapidAPI pays providers through PayPal only (this guide), so PayPal's withdrawal fee decides what a cheap plan is actually worth to you.

1) Lead answer

1. Mainland China resident, business account: withdrawing to a bank in Mainland China by wire costs USD 35.00 per withdrawal (PayPal C2 business fees).
2. Minimum for that wire: USD 150, arriving in 3 to 7 business days (PayPal help: How do I withdraw funds).
3. Same C2 table, Hong Kong bank account: no fee at HKD 1,000 or more, HKD 3.50 below that, both "when no currency conversion is involved". The help page gives an HKD 80 minimum and 3 to 6 business days (same sources).
4. Currency conversion costs extra. Withdrawing in a currency other than the balance currency adds PayPal's conversion fee (C2 fee page). The exact cost to turn a USD balance into HKD for your account is Not verified here.
5. For micro plans the wire fee dominates. After RapidAPI's 25%, a $25 plan nets $18.75, so one $35 wire costs almost two months of that subscriber. Withdrawing at the $150 minimum still loses 23.33% to the wire fee alone.

2) The fee rows, quoted

From the C2 business fee table, "Withdrawing a balance from a business PayPal account":

Source: PayPal C2 business fees. The page says rates apply to accounts of residents of Mainland China. Note that the published table says "or higher" and "or lower" on both HKD rows, so a withdrawal of exactly HKD 1,000 is ambiguous on the page itself. Treat it as Not verified and go above it if it matters.

For comparison, PayPal's Hong Kong business fee page (for HK residents) shows the same HKD 1,000 / HKD 3.50 split for local withdrawals and lists Instant Transfer at 1% (min HKD 10, max HKD 100) (PayPal HK business fees). That page applies to HK residents, not to Mainland accounts.

Eligibility to link a Hong Kong bank account to a Mainland PayPal account depends on PayPal's and the bank's own requirements. Who qualifies is Not verified and is outside the scope of this article.

3) Stack it on a RapidAPI plan

RapidAPI's own docs: a 25% fee, and PayPal fees on top (RapidAPI Payouts and Finance). Arithmetic below uses Python Decimal.

Monthly withdrawals by Mainland wire only make sense once a month's payout is well above $35. Below that, the fee is larger than the revenue.

Batching math (Mainland wire):

• The wire minimum is $150. $35 / $150 = 23.33% of that withdrawal.
• One $25 subscriber nets $18.75/month, so reaching $150 takes 8 months of settled payouts.
• At $300 the fee falls to 11.67%; at $1,000 it is 3.5%. The wire fee is fixed, so larger, less frequent withdrawals cost a smaller share.

HK bank line (only if your account is eligible and no conversion applies): the fee is zero at HKD 1,000 or more. As an illustration only, at an assumed USD/HKD 7.80 that is about $128.21. That FX rate is Not verified and is not from PayPal's page. Any USD→HKD conversion fee is extra and its amount is Not verified here.

4) Fees that this article does not cover

• Receiving fee on RapidAPI's PayPal payout. The C2 page lists a 4.40% + fixed fee for receiving international commercial transactions, and separate PayPal Payouts fees charged to the sender. Which one, if any, hits a provider receiving RapidAPI's payout is Not verified. Check one real payout record.
• Bank-side charges (intermediary or receiving bank wire fees) are not on PayPal's page: Not verified.
• Tax on API income in your jurisdiction: out of scope.

5) What this means for pricing a micro API

• Do not price a public plan near $5 and expect to cash it out monthly from a Mainland account by wire. The $35 fixed fee can be several months of that plan's net.
• Raise the floor or reduce payout frequency. A higher first paid tier, or letting the balance build before one larger withdrawal, are the two levers the public fee page leaves you.
• Model three deductions, not one: RapidAPI 25%, any PayPal receiving or conversion fee (Not verified for your account), and the withdrawal fee.
• Account for the delay. RapidAPI pays roughly two months after the sale month (this guide), and batching to reach $150 adds more months on top.
• Market reality matters more than fees. If a comparable PDF API already sells at $0.10 per 1,000 requests (this guide), a thin plan has little room for a fixed $35 cost.

6) Self-check

• I read the PayPal fee page for my country of residence and my account type.
• My spreadsheet uses 25% (RapidAPI) plus withdrawal fee plus "Not verified" lines for receiving and conversion fees.
• My smallest paid plan still makes sense after one fixed withdrawal fee.
• I only use withdrawal methods PayPal offers my account, under its terms.

7) Sources

• PayPal C2 business fees (English): https://www.paypal.com/c2/business/paypal-business-fees?locale.x=en_C2
• PayPal C2 help, How do I withdraw funds: https://www.paypal.com/c2/cshelp/article/how-do-i-withdraw-funds-from-my-paypal-account-help394?locale.x=en_C2
• PayPal HK business fees: https://www.paypal.com/hk/business/paypal-business-fees
• RapidAPI Payouts and Finance: https://docs.rapidapi.com/docs/payouts-and-finance

Product links: None (no product links).

You can price an API carefully and still ship a listing that confuses buyers or leaves your origin open. This is a pre-publish self-check against what RapidAPI's own Hub Listing docs actually describe.

1) Lead answer

1. General tab is where buyers first judge you: logo, category, short and long description, website, terms of use, visibility, tags, and base URLs (Hub Listing - General Tab).
2. Docs tab README lands on the listing's About tab; the long description lands under the short description on Endpoints. Both accept markdown (Hub Listing - Docs Tab).
3. Definitions hold endpoints, security schemes, and OpenAPI/Postman imports (Hub Listing - Definitions Tab; Configuring API Security).
4. Monetize supports up to four public plans (BASIC, PRO, ULTRA, MEGA). On rapidapi.com the default free BASIC plan allows one million requests per month unless you change it (Hub Listing - Monetize Tab).
5. Gateway: every Rapid Runtime request carries a unique X-RapidAPI-Proxy-Secret. Missing or wrong means the call did not come from Rapid. Copy it from Firewall Settings and enforce it on your origin (Hub Listing - Gateway Tab).
6. Privacy / retention as a Hub field: the General tab has optional Terms of use text; Rapid documents request/response logs "up to 7 days" on the Gateway. A separate mandatory "privacy policy URL" or "data retention days" field for providers is Not verified in the pages reviewed.

2) General tab checklist

From Hub Listing - General Tab:

• Logo. Default is a random image. Upload JPEG/PNG, max 500x500. Hosted on Rapid's infrastructure.
• Category. Exactly one. Buyers browse by category (examples in the docs: SMS, Education, Commerce, Video and Images, News).
• Short description. Shown on Hub tiles and search; truncated if too long. Also shown first on the Endpoints tab.
• Long description. Markdown under the short description on Endpoints.
• Website (optional). Shown on About as "Product Website".
• Terms of use (optional). Markup or a link; opens in a popup from About → Resources. You can paste full text or a URL such as a terms page.
• Visibility. New APIs start private. Making one public on rapidapi.com requires checking the Terms of Service box; team-owned APIs need an org admin approval.
• Tags. Name-value pairs configured by the environment; shown on tiles and used in search filters.
• Base URLs. Set where the Runtime forwards traffic; confirm they point at your production origin.
• Health check. Present on the General tab; whether it is required before going public is Not verified.

3) Docs tab vs long description

From Hub Listing - Docs Tab:

• Docs / README → markdown on the listing About tab (visual editor available).
• Long description (General) → markdown under the short description on Endpoints.

Use either or both. A practical split: About README for auth overview, limits, and failure modes; Endpoints long description for what each resource returns. Images in README use the toolbar or markdown image syntax.

4) Definitions and security

From Hub Listing - Definitions Tab and Configuring API Security:

• Prefer updating endpoints by re-uploading OpenAPI or Postman so you keep one source of truth.
• Path parameters, query params, headers, and body types are defined per endpoint.
• RapidAPI Auth headers are always in play on rapidapi.com because every public Hub API uses the Rapid Runtime. Extra schemes (header, query, basic, bearer, OAuth2, etc.) are optional and stack on top.
• If you add your own auth scheme, document what the consumer must send; the scheme description appears next to Authorization in the listing.

Self-check: call each public endpoint from the playground with only the documented headers. If your origin accepts the same call without Rapid headers, you have a Gateway problem (next section).

5) Monetize tab (plans only — not payout math)

Payout percentages and settlement lag are covered in this guide. For listing readiness, the Monetize docs say:

• Up to four public plans: BASIC, PRO, ULTRA, MEGA, plus private plans (Hub Listing - Monetize Tab).
• Default BASIC is free; on rapidapi.com it allows one million requests/month unless changed. Consumers get emails at 85% and 100% of quota.
• Plan knobs: visibility, type, subscription price, objects/quotas, features (endpoint access), optional approval, optional contract, "Recommended" label.
• Changing a plan after subscribers exist leaves them on the old plan labeled "Deprecated Plan".
• From Monetizing Your API on rapidapi.com: Free / Pay Per Use / Freemium / Paid; Free APIs cannot collect payments through Rapid; freemium and paid require a credit card even for a free tier; above 500K requests/month the minimum is $0.00003 per call (example: 2M/month → at least $45/month).

Conflict to remember: Monetizing page cites a 500K free-plan cap; Monetize Tab cites 1M for default BASIC on rapidapi.com. Which cap a brand-new listing gets is Not verified until you read your own Studio plan.

Suggested list prices in the monetizing docs (BASIC free / PRO \(25 / ULTRA \)75 / MEGA $150) are recommendations, not requirements.

6) Gateway: Proxy-Secret, secrets, and logs

From Hub Listing - Gateway Tab:

• On rapidapi.com, APIs must use the Rapid Runtime.
• Rapid adds X-RapidAPI-Proxy-Secret to every request. Unique per API. If missing or different, treat the call as not from Rapid.
• Copy the value from Firewall Settings and validate it in your API gateway or app.
• Optional: allowlist the published Rapid Runtime IP list (same page).
• Secret headers & parameters: name/value pairs Rapid injects and hides from consumers (useful for a single upstream API key). Transformations are the more flexible alternative when values differ by plan or endpoint (Request and Response Transformations).
• Runtime benefits listed include timeout/rate/size/quota enforcement, monetization, analytics, mocking, transformations, detailed request and response logs (up to 7 days), and automatic CORS for playground tests.

Self-check: from a non-Rapid client, call your origin URL directly. The request must fail your Proxy-Secret (and/or IP) check. Then call via the Hub playground and confirm success.

7) Privacy and data retention — what the Hub docs say vs what they do not

Documented:

• Optional Terms of use field on General (can hold privacy text or a link) (General Tab).
• Rapid Runtime keeps detailed request/response logs up to 7 days (Gateway Tab).

Not verified from the Hub Listing pages reviewed:

• A dedicated mandatory privacy-policy URL field.
• A Hub-enforced retention period for your storage of uploaded files (for example PDF bodies you write to disk).
• Whether Rapid's 7-day logs include full payloads for all content types, who can access them, and how deletion requests work.

If your API accepts uploads or personal data, say in Terms of use / README what you store, for how long, and what you delete — and make the implementation match. Do not invent a RapidAPI retention SLA that the docs do not state.

8) One-page pre-publish checklist

• Logo, category, short description, long description, README filled.
• Terms of use states refunds, abuse, and (if relevant) data handling.
• Visibility set to public only after playground tests pass.
• OpenAPI matches live endpoints; security schemes match what buyers must send.
• Plans: free BASIC limits honest; paid floors respect $0.00003 above 500K if applicable.
• X-RapidAPI-Proxy-Secret enforced on origin; direct hits rejected.
• Secret upstream keys live in Gateway secrets or transformations, not in consumer-visible docs.
• PayPal linked and fee model understood via this guide before turning paid plans on.

9) Sources

• Hub Listing - General Tab: https://docs.rapidapi.com/docs/hub-listing-general-tab
• Hub Listing - Docs Tab: https://docs.rapidapi.com/docs/hub-listing-docs-tab
• Hub Listing - Definitions Tab: https://docs.rapidapi.com/docs/hub-listing-definitions-tab
• Configuring API Security: https://docs.rapidapi.com/docs/configuring-api-security
• Hub Listing - Monetize Tab: https://docs.rapidapi.com/docs/hub-listing-monetize-tab
• Monetizing Your API on rapidapi.com: https://docs.rapidapi.com/docs/monetizing-your-api-on-rapidapicom
• Hub Listing - Gateway Tab: https://docs.rapidapi.com/docs/hub-listing-gateway-tab
• Hub Listing - Request and Response Transformations: https://docs.rapidapi.com/docs/hub-listing-request-and-response-transformations

Product links: None (no product links).

PDF-to-text looks like an easy API to sell: everyone has PDFs. That is exactly why the shelf is crowded. Before listing one, check three things: who is already there, what they charge, and whether anyone can prove demand.

1) Lead answer

1. Competitors exist at every price point, from free tiers to big cloud vendors. A total count of PDF APIs on RapidAPI is Not verified: RapidAPI search results load with JavaScript and could not be captured.
2. Price per 1,000 requests ranges about 200x: from $0.10 (OCR.space PRO) to about $20 (pdfRest Pro), with small RapidAPI listings in between.
3. Hard usage numbers are mostly hidden. RapidAPI shows a "Popularity" score, service level and latency, but not paying-subscriber counts. Revenue for any listing is Not verified.
4. After RapidAPI's 25% fee, a $5 plan nets $3.75 before PayPal fees (RapidAPI Payouts and Finance).

2) Who is already selling

On RapidAPI (figures from a search-engine snapshot of the listing pages; the live pages render with JavaScript, so every number here is Not verified live):

Direct vendors (live pages fetched with curl, figures confirmed):

3) Price per 1,000 requests

Requests are not the same unit everywhere: OCR.space limits pages per PDF, pdfRest counts calls, PDF.co counts credits. Compare by your own typical document, not by headline numbers.

What this means for a new listing: a bare "PDF in, text out" endpoint competes with OCR.space at $0.10 per 1,000. You need a reason to cost more: better tables, more languages, larger files, or simpler auth.

4) Usage and demand signals you can verify

• RapidAPI Popularity, service level, latency: public on the listing, but the formula behind Popularity is not documented in the pages reviewed (Not verified).
• Paying subscribers or revenue: not public on RapidAPI. Not verified for every listing above.
• Providers themselves can see consumer usage in the "Requests in last 60 days" column in Studio (Monetize Tab docs), but only for their own API.
• "Most popular" badges on direct vendor pages (PDF.co Business 1, pdfRest Pro) are marketing labels, not usage data.

Bottom line: there is no verified public number showing how much any small PDF API earns on RapidAPI. Treat any claim otherwise as Not verified.

5) What not to overpromise on your own listing

• Scanned PDFs. Text extraction and OCR are different. If OCR is optional or limited, say so.
• Languages. List the OCR language packs you actually ship.
• Page and size limits. State them; competitors do (OCR.space's 3-page cap is right on its pricing table).
• Failed requests. Google says it does not bill failed requests (4xx/5xx) (Document AI pricing). On RapidAPI, quota counting for your errors depends on your setup; whether errored calls count toward a subscriber's quota is Not verified, so test it before promising "no charge on failure".
• File retention. If you do not store uploaded PDFs, say that plainly, and make sure it is true.
• Popularity. Do not quote another listing's score as proof of market size.

6) Sources

• RapidAPI listing: PDF To Text Converter: https://rapidapi.com/rgtimothy/api/pdf-to-text-converter (and /pricing)
• RapidAPI listing: OCR Wizard: https://rapidapi.com/ai-engine-ai-engine-default/api/ocr-wizard (and /pricing)
• RapidAPI listing: OCR Nanonets: https://rapidapi.com/nanonetsocr-nanonetsocr-default/api/ocr-nanonets/pricing
• OCR.space API: https://ocr.space/ocrapi
• pdfRest pricing: https://pdfrest.com/pricing/
• PDF.co pricing: https://pdf.co/pricing
• Google Document AI pricing: https://docs.cloud.google.com/document-ai/pricing
• RapidAPI Docs, Payouts and Finance: https://docs.rapidapi.com/docs/payouts-and-finance
• RapidAPI Docs, Hub Listing - Monetize Tab: https://docs.rapidapi.com/docs/hub-listing-monetize-tab

Product links: None (no product links).

If you are about to list a paid API on rapidapi.com, the money side is short to describe but easy to misread. Here is what the official docs actually say, what they contradict, and what they do not say at all.

1) Lead answer

1. Fee: a flat 25% on all payments made through the API Hub, effective November 15, 2025. A $100 plan pays you $75 (Payouts and Finance).
2. PayPal fees are on top. The 25% "does not cover the fees associated with payouts processed through PayPal" (same page).
3. PayPal is the only payout method. "Rapid currently only pays out API providers via PayPal... we cannot accommodate other payout methods" (same page).
4. Timing: about two months. Charges in a month are consolidated and processed "at the end of the following month"; the docs' January example arrives "in the first week of March" (same page).
5. You are paid only on settled money. Payouts happen only after the card company or bank has fully settled the developer's payment; refunds and chargebacks are offset against what you are owed (same page).
6. Minimum payout threshold: Not verified. The docs pages reviewed do not state one.

2) The fee, with real numbers

The suggested BASIC free / PRO \(25 / ULTRA \)75 / MEGA $150 ladder is RapidAPI's own recommendation (Monetizing Your API on rapidapi.com).

A contradiction to know about. The same payouts page still carries a worked example: three $10 PRO subscriptions should pay "$24 less any applicable PayPal fees". $24 out of $30 is a 20% fee, not 25%. At 25% the answer would be $22.50. The example most likely predates the November 2025 change, but which number RapidAPI applies to your account today is Not verified until you see a real statement. Budget with 25%.

PayPal's own fee on the incoming payout is not documented by RapidAPI; the amount for your country and account type is Not verified here. Check PayPal's fee page for your region.

3) The timeline, month by month

Using the docs' own example:

• January: developers subscribe on Jan 1, 5 and 20.
• End of February: January's charges are processed ("end of the following month").
• First week of March: the money lands in PayPal.

So your first sale on day one of a month reaches you roughly 60+ days later. Plan cash flow and any hosting bills accordingly.

What triggers a charge at all: a first subscription to a paid plan, a monthly renewal, or an overage (Payouts and Finance).

4) Things that shrink or delay a payout

• Forgiveness requests. When a developer runs up accidental overages, RapidAPI will not refund them "without your explicit permission". The call is yours.
• Disputes and chargebacks. RapidAPI investigates; if a refund or chargeback happens, it offsets your payout by that amount.
• Failed payments. RapidAPI retries, then cancels the subscription. You only get paid once a payment is final.
• No PayPal linked. If you never link PayPal, "there is unfortunately no way for us to send you money". RapidAPI says it will email you at least three times.

All from Payouts and Finance.

5) Pricing rules that affect revenue

From Monetizing Your API on rapidapi.com:

• Four API types: Free, Pay Per Use, Freemium, Paid. Free APIs cannot collect payments through Rapid.
• Freemium and paid plans require a credit card, even for the free tier of a freemium API. Expect some drop-off at that step.
• Price floor above 500K requests/month: at least \(0.00003 per call over 500K. A 2M-request plan must cost at least \)45/month (1.5M x $0.00003). The floor applies to overage prices too.
• Overage advice: usually no more than $1 per call unless your own cost is higher.
• You can have up to four public plans (BASIC, PRO, ULTRA, MEGA) per API (Hub Listing - Monetize Tab).

Another inconsistency: the Monetizing page says free plans are capped at 500K requests/month, while the Monetize Tab page says the default free BASIC plan on rapidapi.com allows one million. Which cap applies to a new listing is Not verified.

6) Tax forms

The only tax document the payouts page mentions: "W9 forms are also available upon request" from RapidAPI support, plus custom invoices on request (Payouts and Finance). That is RapidAPI's own W-9 for your records.

What the docs reviewed do not say: whether non-US providers must submit a W-8BEN, whether RapidAPI withholds US tax, or whether it issues 1099 or 1042-S forms. All of that is Not verified. Ask support in writing before your first payout and keep the reply.

7) Honest self-check before you turn on paid plans

• PayPal account linked, in a country where it can receive business payments.
• Spreadsheet uses 25% plus a PayPal fee, not 20%.
• Cash-flow plan assumes about two months from sale to cash.
• Hosting cost per call is below your net price per call after fees.
• Overage policy decided in advance, including how you answer forgiveness requests.
• Tax question sent to support and answer saved.
• Listing does not count "subscribers" as paying customers: free and freemium subscribers are not revenue.

8) Sources

• RapidAPI Docs, Payouts and Finance: https://docs.rapidapi.com/docs/payouts-and-finance
• RapidAPI Docs, Monetizing Your API on rapidapi.com: https://docs.rapidapi.com/docs/monetizing-your-api-on-rapidapicom
• RapidAPI Docs, Hub Listing - Monetize Tab: https://docs.rapidapi.com/docs/hub-listing-monetize-tab

Product links: None (no product links).

Selling a module on Odoo Apps means you also inherit a refund process you do not control end to end. Here is how it runs and what a vendor can do about it.

1) Lead answer

1. Buyers can file claims within two months of purchase (Refund Policy).
2. A claim starts when the buyer clicks the support button on their order. From that date the vendor has 15 days to fix the issue or reach an agreement (Refund Policy).
3. After 15 days without agreement, either party can ask Odoo to intervene, and Odoo decides on the refund (Refund Policy).
4. A refunded buyer must agree to stop using the app and delete all copies (Refund Policy).
5. The order-page channel matters: the FAQ tells buyers not to contact the publisher elsewhere because it is the only channel where the refund timing applies (Apps FAQ). Note the FAQ calls it "the two weeks time" while the Refund Policy says 15 days; which one Odoo applies in practice is Not verified, so plan for the shorter.

2) When the buyer gets a refund

Per the Refund Policy, any one of these is enough:

• A bug not fixed within the allotted time.
• A feature advertised on the description page is missing.
• The module does not install properly on the advertised version.
• The module breaks the Vendor Guidelines.
• The module's license is wrong.
• Fraud or a stolen card.

3) When the buyer does not

• The request is a new feature not advertised in the description or in your messages.
• You fixed the bug after the claim.
• The module works but does not fit the buyer's specific needs.
• The buyer's database is on Odoo Online (third-party apps cannot be installed there).
• The buyer bought the wrong version.

Since 13.0, each version is a separate product, so "wrong version" is a real outcome (Refund Policy).

4) What the vendor owes

The FAQ draws the line: you are expected to fix bugs that stop the app working as advertised, and to give configuration advice (email or docs) when the buyer's server is misconfigured. You are not expected to build custom features or configure their server for free (Apps FAQ). Not supporting buyers is also on the FAQ's list of reasons a module can be removed.

The manifest support email is shown only to buyers (Vendor Guidelines). Monitor it.

5) Dates and money, worked

Worked example:

• Purchase 2026-10-15 → claims allowed until about 2026-12-15 (read as two calendar months; how Odoo counts the edge day is Not verified).
• Claim opened 2026-11-03 → your 15 days end 2026-11-18. How Odoo counts day one is Not verified; treat the claim date as day 0 and answer within days, not on day 14.
• Your share is 70% of revenue (Apps FAQ): EUR 9.00 (the minimum price) → EUR 6.30; EUR 49.99 → EUR 34.99; EUR 100.00 → EUR 70.00. Whether a refund after payout is clawed back from your next balance is Not verified.

There is also a note to vendors: once Odoo issues a refund, "you have 30 days to validate it/accept it." What happens if you do not is Not verified.

6) Write the listing to win claims

Most refund triggers come down to what your description page promised:

• List only features that ship today; put roadmap items in a separate, clearly labeled section or leave them out.
• State supported versions exactly, and that it does not run on Odoo Online.
• Name every dependency, especially Enterprise ones.
• Make sure the manifest license matches the LICENSE file (a wrong license is a refund trigger).
• Put setup steps in docs, so "configuration advice" can be a link.
• Answer every claim on the order thread, with dates, so the record is there if Odoo steps in.

7) What this article does not do

• No manifest or image checklist (that is a separate guide; multi-series is a separate guide), payout banking (this guide), or license choice (this guide).
• No data on how often Odoo sides with buyers (Not verified).

Sources

• Odoo Apps Sales Conditions / Refund Policy — https://apps.odoo.com/apps/refund-policy (fetched 2026-10-15)
• Odoo Apps FAQ — https://apps.odoo.com/apps/faq (fetched 2026-10-15)
• Odoo Apps Vendor Guidelines — https://apps.odoo.com/apps/vendor-guidelines (fetched 2026-10-15)

Most extension guides stop at "click Submit". This one starts when the review email lands and you need to know how bad it is and what to do next.

1) Lead answer

1. The two-word code is a lookup key. Every violation gets a human-readable ID made of a color and an element (for example, Yellow Magnesium = the extension does not behave as expected). The troubleshooting page lists 23 of them with common causes and fixes (Troubleshooting).
2. Rejection happens to a submission. Your live listing, description, images, privacy disclosures and published CRX stay unchanged, and users are not notified (Review process).
3. Warning happens to a published item with a minor violation: typically 7 to 30 days to ship a fixed version, otherwise takedown. The item stays installable during the warning (Review process).
4. Takedown removes the item from the store, but in most cases it is not permanent: submit a version that fixes the violation and pass review (Review process).
5. Malware / extreme violations: immediate takedown, no notice email, disabled on user devices and cannot be re-enabled (Review process).
6. Appeal takedowns and warnings from the item detail page in the Developer Dashboard (Appeal button); account suspensions from the account page. Other issues go through the One Stop Support form (Review process).

2) Decode the color

From the 23 IDs on the troubleshooting page, the colors cluster like this (our grouping, read from the list; Google does not publish a color legend — Not verified as an official taxonomy):

Practical read: Yellow and Purple are usually fixable in a resubmission. Red and Blue Titanium are about intent signals; treat them seriously before appealing.

3) The most common fixable one: Yellow Magnesium

The page's own checklist (Troubleshooting):

• Test the exact files you uploaded, not your dev folder. Pack the extension yourself and drag the .crx onto chrome://extensions; packed and unpacked can behave differently.
• Every file named in manifest.json must exist at that path. Watch case sensitivity (Background.js vs background.js).
• A server-side outage during review counts as "not working". Make error states visible to the user.
• If the extension needs an account or special network, say so in the listing and in the UI (and give reviewers test instructions).
• Test on a flaky connection: timeouts, HTTP 400/500, certificate errors.
• If you cannot reproduce the reviewer's problem, ask developer support which flow failed.

4) Blue Argon in one paragraph

MV3 extensions must not run remotely hosted code: no external <script> sources, no eval() of fetched strings, no interpreter for remote commands even if fetched "as data". Logic must be self-contained; external resources may supply data only (Troubleshooting).

5) Timeline math for a warning

Worked example: warning email on 2026-10-15 → takedown no earlier than 2026-10-22 (+7 days) and no later than 2026-11-14 (+30 days), depending on the violation. The email states your actual window; do not plan on 30.

Review itself: "within a few days" for most, up to a few weeks; if pending more than three weeks, contact support. Expect longer reviews for new developers, new items, dangerous permissions, big code changes, broad host permissions, and after a rejection or warning (Review process). Support requests get an email with a unique ID within minutes; the page says responses may take up to three days depending on queue and violation.

6) Fix or appeal?

Whether an appeal pauses a warning countdown is Not verified — the docs do not say. Assume it does not.

7) What this article does not do

• No pre-submit checklist (that is a separate guide), privacy-policy walkthrough (this guide), or permission design (this guide).
• No claim about appeal success rates or turnaround beyond what the docs state (Not verified).

Sources

• Troubleshooting Chrome Web Store violations — https://developer.chrome.com/docs/webstore/troubleshooting (fetched 2026-10-15)
• Chrome Web Store review process — https://developer.chrome.com/docs/webstore/review-process (fetched 2026-10-15)

Not legal or investment advice. Mechanics come from docs.apify.com (PPE, Monetize, Actors in Store, JS/Python SDK pay-per-event), archived 2026-10-15 (Asia/Shanghai). Console labels and scoring evolve — re-open the pages before you ship pricing. This article links none of our Actors.

This article is not a full monetization overview. Related reading: this guide (PPE vs rental vs usage), this guide (publish / price-change seam), and this guide (quality score and daily Store test). Here the only job is: how to define and charge events so a Store visitor can predict the bill.

1) Lead answer

1. An event is a specific, measurable action your Actor triggers in code and charges for — commonly creating a result, processing an item, or calling an external API (PPE).
2. You must pick a primary event — the one that best represents main value. It is highlighted on the Actor detail page so users see what they pay for (PPE).
3. Two synthetic events can charge automatically: apify-actor-start (startup; Apify covers first 5 seconds of compute when enabled) and apify-default-dataset-item (each item written to the default dataset). Don’t also Actor.charge() the synthetic start yourself — it fails. Default start price in docs: $0.00005 (= $0.05 per 1,000 starts); count scales with RAM (≤1 GB → 1×; then +1× per extra GB) (PPE).
4. Custom events are named, described, priced, and charged from your code (Actor.charge / pushData with an event name). Prefer one charge per unit of work, not a big count batch at the end (SDK JS, SDK Python).
5. Double-counting risks: charging both a custom “result” event and leaving apify-default-dataset-item on for the same push; charging start twice (custom + synthetic); batching with count without checking chargedCount / charged_count; retries without an idempotency key (Python SDK: same key not re-charged for three minutes) (PPE, SDK Python).
6. Disclose in the Store description / README: event names and prices, which event is primary, whether platform usage is included or PPE + usage is on, and that users can set a max charge per run (Actors in Store, PPE).

2) Contrast only as needed (not a full monetization guide)

Creator profit reminder (context only; details in this guide): profit = (0.8 * revenue) - platform costs for paid-plan users (PPE, pricing & costs).

3) Naming and mapping events to visible results

Docs best practices (PPE):

• Limit the number of events. Fewer events → easier cost prediction.
• Avoid stacking many events for one user-visible result (makes the Actor look expensive and opaque).
• Map charges to something the user can see — a dataset row, a stored file, a status message. Examples in docs: post, profile, processed-image, ai-analysis.
• If the work is invisible (external API, AI step), push a record or status so the invoice line has a twin in the run output.
• Charge after results are saved and available; don’t bill for work the user cannot access if the run aborts mid-batch.
• Charge as work completes, not in one end-of-run batch — early stop otherwise leaves unbilled (for you) or confusing (for them) gaps.

Invalid input: Docs allow charging for work that discovers a 404-style failure, and recommend returning an error item with a clear code instead of failing the whole run. If you charge for errors, say so in the README — otherwise buyers read “per result” as “per useful result.”

4) Synthetic vs custom — honesty table

Start event RAM examples from docs (at default $0.00005): 128 MB or 1 GB → 1 event; 4 GB → 4 events ($0.0002). Raising the price does not buy more free compute. Deleting the synthetic start removes the free 5 seconds.

5) Double-counting and idempotency self-check

Not verified: exact platform-side idempotency behavior if you call the Charge API without the SDK; docs say you must implement idempotency yourself in that case.

6) What to put on the Store page / README

1. Primary event name + price (matches Console).
2. Full event list with one-line descriptions a non-expert can map to output.
3. Whether platform usage is included or separate (PPE + usage).
4. Example cost: “~N primary events for a typical input of …”.
5. Free-plan limits, if any — stated up front, graceful exit, not a fake crash (Monetize).
6. “Set max total charge per run” reminder.
7. If you charge for error/404 items, say so next to the event description.

7) Self-check

• Primary event is the one users would guess from the title.
• No synthetic + custom pair bills the same user-visible unit twice.
• Event titles in Console = names in README = names in status/dataset fields where practical.
• Local test with ACTOR_TEST_PAY_PER_EVENT and the charging-log dataset before go-live (SDKs).
• PPE + usage only as a temporary pricing probe; docs say it hurts transparency / quality score.
• Memory min/max set so users can’t inflate platform cost past your event math.
• No claim of a separate “pay-per-result” Store product — say PPE / dataset-item event instead.

8) Not verified

• Quality-score weights for pricing transparency (this guide: algorithm unpublished).
• Internal Apify charge ledger beyond documented ChargeResult fields and the SDK idempotency window.
• That every Console screenshot label matches docs on a future date.
• Exact residual platform-cost duration after the spend limit aborts a run (“short time” in docs — no seconds published except the 30 s graceful abort window).

9) Bottom line

PPE honesty is an event map, not a slogan. Name one primary event, keep the list short, make every charge leave a footprint the user can see, and strip synthetic events that would double-bill the same unit. If the Store page cannot predict the invoice from the README, the design is not done.

Not legal or marketplace advice. Mechanics come from Gumroad Help articles archived 2026-10-15 (Asia/Shanghai). Re-open them before you change a live product. This article links none of our products.

This article is not a past-buyer updates checklist or a refunds guide — see this guide and this guide. Here the job is narrower: what buyers actually open after they pay, which seller toggles change that experience, and which file-size / streaming numbers you may quote without inventing limits.

1) Lead answer

1. Three access paths to the same Content: email receipt "View content", the product page "already own" card (when Gumroad recognizes the buyer), and Library after they create an account with the same email used at checkout (Help 199, Help 198, Help 247).
2. Content tab is the delivery pipe. Files, pages, folders, stamped PDFs, code blocks, embed videos (download or stream-only), and embedded emails live there (Help 149). Buyers who open the product from Library see that Content.
3. Documented size limits (Help 289): free / $0 PWYW floor → max product size 250 MB; price greater than $0.99 → largest single file 20 GB (Help also says “priced higher than $1” in the intro — same article); "Download all" only if total content < 500 MB (else upload a ZIP yourself).
4. Read vs download: PDF/EPUB up to 32 MB can show an in-browser Read button; EPUB over 32 MB is download-only; you can turn Read/Kindle off per file (Help 247, Help 198, Help 112).
5. Stream vs download for video: you can leave downloads on, or set Disable file downloads (stream only). Streaming SD is 480p, HD 1080p; 4K is reduced to 1080p for streaming. Transcoding starts after the first successful sale and may take minutes to hours (Help 43).
6. App ≠ desktop. ZIP / Mobi-style packages often do not show usefully in the mobile app; app-friendly types are listed in Help 112. Don’t promise “works in the Gumroad app” for a ZIP-only product (Help 247 FAQ, Help 112).

2) What the buyer sees (mental model)

Folders on the download page start collapsed unless you enable Start expanded, or there is only one top-level folder (Help 149). A buyer who “can’t find the zip” may simply not have opened the folder.

3) Seller toggles that change the experience

Browsers: Gumroad supports the last four major updates of Edge, Safari, Chrome, and Firefox; outdated browsers can cause upload and purchase errors (Help 53). Useful for support macros; not a sales boast.

4) Claims you may make vs invent

5) Seller self-check (delivery honesty)

• Sales page language matches stream only vs downloadable for every video.
• Free / $0 products stay under 250 MB total, or the price is raised above $0.99 before shipping large archives.
• If total Content ≥ 500 MB, the page tells buyers to use the ZIP (or named parts), not “Download all.”
• PDF/EPUB: either offer Read honestly, or disclose that Read/Kindle is off.
• App claim only if files are in Help 112’s audio/video/PDF/EPUB lists — not ZIP-only.
• Folders: critical files either top-level or in a folder set to Start expanded.
• Test purchase: receipt → View content; second check with Library account on the same email.
• Don’t borrow the update story from this guide here: if you promise “lifetime updates,” you still need Content + email (Help 169) — that is a separate article.

6) Not verified

• Library visibility latency after you save Content.
• Whether every mid-life Content replace triggers a “file ready” style mail (do not rely on it; see this guide).
• A published hard cap on number of files per product (Help 289 says you can add as many as you want).
• Full “Content protection on Gumroad” article mechanics (related link noted in Help 43; not archived this run).
• Help article 80 (streaming video rentals URL returned the Help index on fetch day — do not cite).

7) Bottom line

Buyers don’t live on your product editor. They live on receipt → download page and Library → tile → Content. Quote only the file-size and streaming numbers Help prints (250 MB / 20 GB / 500 MB Download-all / 32 MB Read / 480p·1080p stream). If your listing promises an app, a browser reader, a one-click Download-all, or a downloadable 4K file, check the matching toggle and limit first — or rewrite the listing.

Not legal or investment advice. Mechanics come from docs.apify.com (Actor quality score, Actor testing in Apify Store, Automated tests for Actors), archived 2026-10-15 (Asia/Shanghai). Apify says the scoring algorithm keeps evolving, so re-open the pages before you rely on any detail. This article links none of our Actors.

Publishing an Actor is the start, not the finish. Two systems keep judging it afterwards: a quality score that feeds search ranking, and a daily automated test that can label it under maintenance and eventually deprecated. Neither needs you to do anything wrong. A target site changing its HTML is enough.

1) Lead answer

1. Quality score: 0–100, shown in Console > Insights > Actor quality. It correlates strongly with ranking in Apify Store search and in the Apify MCP server's search-actors tool used by AI agents. No position is guaranteed. Console search is personalized per user.
2. It moves without you. It is recalculated several times a day, it is relative to other Actors, and the algorithm changes. Recommendations may linger after you've fixed the issue.
3. Daily Store test: Apify runs your Actor with its prefill input. The run must end Succeeded, with a non-empty default dataset, within 5 minutes.
4. Failure calendar: 3 consecutive failing days → you're notified and the Actor is marked under maintenance. 14 more days → a second notice. 14 more → deprecated.
5. Recovery: fix and rebuild, and the test picks it up within 24 hours. Or, if the target site was at fault, pass the majority of test runs over the next 7 days and it is marked healthy automatically.
6. Actors that need auth, or that legitimately run more than 5 minutes, always fail. Contact support to ask for an exclusion. Don't game the prefill instead.

2) The eight categories and what you actually control

Weights: Not verified. Apify doesn't publish them, so don't write "pricing is 20% of the score" or anything like it.

3) The daily test, step by step

• Prefill is the test input. It's the prefill in your input schema, not default. A prefill that scrapes 10,000 pages or needs a cookie will fail every day.
• Keep the default run under 5 minutes, with at least one dataset item. A run that succeeds but pushes nothing still fails.
• Treat the prefill as the demo, the test, and the first-run experience all at once. The same run that decides under maintenance is what a new user sees first.

Hypothetical calendar (first failing test on 2026-10-15):

So you have about a month from first failure to deprecation, but the public under maintenance label arrives on day 3. The intro of the same page says "broken for more than a month." Whether that and the 3+14+14 count run on the same clock: Not verified.

Majority over 7 days: 4 of 7 passing (0.571) qualifies and 3 of 7 (0.429) doesn't, assuming one test per day. Whether the count is "7 runs" or "all runs in the window": Not verified.

4) Your own tests (so you hear first)

Apify's guide recommends the public Actor Testing Actor:

1. Create 1–5 test tasks, including one with the default configuration.
2. Set a low maxItems to save credits; run heavy-data tests less often.
3. Assert status SUCCEEDED, no ReferenceError/TypeError in the log, retries below a threshold, runtime within a range, a non-empty dataset, and the fields in the expected shape.
4. Schedule it, then review the results weekly.

A scheduled test that mirrors the Store test (prefill, 5-minute budget, non-empty dataset) is the cheapest early warning you can get.

5) Honest language while the score or status is bad

Say:

• "Temporarily under maintenance: the target site changed; fix in progress" (if that's true).
• "Requires your own login; excluded from automated tests by arrangement with Apify" (only after support confirms).

Don't say:

• "Top-ranked" or "#1 in Store." Ranking is personalized in Console and not guaranteed anywhere.
• "Quality score 90+" as a lasting badge. It moves daily, relative to other Actors.
• "Always works." The daily test is public evidence against you the moment it fails.

6) Self-check

• Prefill run finishes Succeeded, with ≥1 dataset item, in < 5 min.
• The input schema validates (Reliability).
• Limited permissions are on (Trustworthiness).
• Title, README, and schemas use the same terms (Congruency).
• Your own scheduled test runs and is reviewed weekly.
• Auth/long-run Actors: exclusion requested from support, not hacked around.
• Listing copy makes no ranking or score promises.

Not verified

• Category weights inside the quality score.
• How "majority of test runs in the next 7 days" is counted.
• Whether "broken for more than a month" and the 3+14+14 schedule are the same clock.
• Whether a deprecated Actor returns to healthy after a fix, or must be republished.
• Whether Actors excluded from the daily test lose Reliability points.

Not legal advice. Mechanics come from developer.chrome.com (Declare permissions, Permission warning guidelines, activeTab, permissions API) and the Chrome Web Store "Use of Permissions" policy, archived 2026-10-15 (Asia/Shanghai). Chrome changes; re-read the pages before you ship. This article links none of our products.

A privacy policy and the Privacy practices tab describe what you do with data. The manifest decides what you can reach. If the two disagree, users find out at install time, and reviewers find out sooner. This piece is about getting the manifest right and describing it truthfully.

1) Lead answer

1. Ask for the narrowest permission that works. The policy says that if more than one permission could implement a feature, you must request the one with the least access, and you must not "future proof" by requesting permissions for features you haven't built.
2. activeTab shows no install warning. It grants temporary access to the current tab only after a user gesture (action click, context-menu item, keyboard command, omnibox suggestion). Access lasts while the user stays on that origin and ends when they navigate away or close the tab. It never covers chrome:// pages.
3. Optional permissions are granted at runtime, via permissions.request() called inside a user gesture. That lets you explain why at the moment the user turns the feature on.
4. Adding a required permission that has a warning disables your extension for existing users until they accept it. Adding an optional permission does not.
5. Some permissions cannot be optional: debugger, declarativeNetRequest, devtools, geolocation, mdns, proxy, tts, ttsEngine, wallpaper (ChromeOS). If you need one, it has to be in permissions from day one, or added later at the cost of an update prompt.

2) The five manifest keys

Host permissions cover more than injection: fetch() from the service worker, reading tab url/title/favIconUrl, webRequest, cookies, and declarativeNetRequest header changes. Make sure your listing does not say "we only touch the page you click" when host_permissions says https://*/*.

Warnings can hide each other. The tabs warning does not show if you also request <all_urls>. A short warning list is not evidence of narrow access, so don't write listing copy based on what the dialog happened to show.

3) Pick the mechanism per feature

Docs-confirmed trade-off: required permissions mean fewer prompts and guaranteed presence; optional permissions mean less standing access, a just-in-time explanation, and upgrades that don't disable the extension.

4) The update trap

The Permission warning guidelines say this directly: when an update adds a permission that triggers a warning, Chrome disables the extension until the user accepts the new permission. For a paid or licensed extension, that means active users may suddenly find the tool off, and every one of them has to say yes again.

Before shipping an update that touches permissions:

• Diff permissions, host_permissions, and content_scripts.matches against the live version. All three can trigger the warning.
• Ask whether the new capability can be optional instead. An upgrade that only adds optional permissions does not disable the extension.
• Test the upgrade path with Google's Extension Update Testing Tool, or pack it manually with the same .pem and update over the old install. You'll see the exact prompt users will see.
• Write the changelog line before release: what new access, and why.
• Remove permissions you no longer use (permissions.remove()). Note: re-requesting a removed permission "usually" re-adds it without a prompt, so don't tell users that removal forces a fresh consent.

How long a disabled extension stays disabled, and whether Chrome re-prompts users who ignore the banner: Not verified.

5) Listing and onboarding language

Say:

• "Works on the tab you're viewing, only when you click the icon" (true for activeTab).
• "Optional: grant access to example.com to enable auto-fill there" (true for optional host permissions).
• "Needs proxy permission at install because it routes traffic. Chrome won't let this be optional."

Don't say:

• "No permissions required" when the install dialog shows any warning.
• "Only reads the current page" alongside <all_urls> in host_permissions.
• "We'll never ask for more access" (you can't promise future manifests).
• "Works in incognito / on local files" without telling users to turn it on themselves on the extension's details page. Both need a user toggle, and you can check them with extension.isAllowedIncognitoAccess() / isAllowedFileSchemeAccess().

6) Self-check before you submit

• Every entry in permissions/host_permissions maps to a shipped feature (no future-proofing).
• Every click-triggered page feature tried activeTab first.
• Every non-core feature uses optional permissions, requested inside a click handler.
• Non-optional APIs are listed and justified in plain words.
• Listing copy matches the broadest access in the manifest, not the shortest warning list.
• The upgrade prompt was tested with the same signing key.
• The exact current warning text for each permission was checked against the Permissions reference. Not verified here.

Not verified

• Exact current warning strings per permission in Chrome stable.
• Whether adding only optional permissions changes Chrome Web Store review time.
• Whether users who ignore the "new permissions" prompt are re-prompted automatically.

Not legal advice. Rules come from Obsidian's "Developer policies" page (docs.obsidian.md/community-directory/developer-policies, source text archived 2026-10-15, Asia/Shanghai). Re-read it before you submit. This article links no plugin.

You can put a paywall, a login, or a banner in an Obsidian plugin and still stay listed. The condition: say so in the README. A few things are banned outright, and no README wording fixes those.

1) Lead answer

1. Banned outright: obfuscated code, dynamic ads loaded over the internet, static ads outside your own UI, client-side telemetry, self-installing or self-updating code/dependencies, and themes loading network assets.
2. Allowed only if "clearly indicated in your README": payment for full access, account for full access, network use (which services, and why), file access outside vaults (why), static ads inside your own UI, server-side telemetry (with a privacy-policy link), closed source (case by case).
3. Licensing: a LICENSE file, compliance with upstream licenses (README attribution if required), and no use of "Obsidian" that suggests a first-party product.
4. Forks: only with the original author's public written approval, or after 6+ months of inactivity plus a 30-day notice. The original author must be credited.
5. Enforcement: users open an issue first and escalate after 7 days. Obsidian may give you "a reasonable timeframe" or remove you immediately (malicious, uncooperative, repeat).

2) Map your monetization to the policy

Not verified: where the line between a license-key check and "telemetry" falls. The page does not define it. Disclose the call as network use either way.

3) A README block you can adapt

## Disclosures
- Payment: core features are free; <features> need a paid license.
- Account: not required / required for <feature>.
- Network: contacts <host> to <purpose>. Sends <data>. Nothing else.
- Files outside the vault: none / <path>, because <reason>.
- Ads: an upgrade notice appears only in this plugin's settings tab.
- Telemetry: no client-side telemetry. Server logs: <what>, see <privacy policy URL>.
- License: <SPDX id>. Third-party code: <list + attribution>.

4) Forks and "Pro" clones

Re-publishing a popular free plugin with a paywall is a fork. It needs public written approval, or proof of 6 months of silence followed by a 30-day public notice. If you only borrowed the idea, the policy says to start a fresh repo that inherits no code without permission.

5) Not verified

• The length of the "reasonable timeframe" before removal.
• Whether disclosures are checked at submission or only after a report.
• Whether a plugin removed from the directory keeps working for existing installs.

6) Bottom line

Payment, accounts, and in-plugin upsells are allowed if you disclose them. Hidden behaviour is what gets plugins removed: ads outside your view, client analytics, obfuscation. Write the disclosure block before the paywall code.

Not legal advice. Quotes come from Odoo's official Licenses page (odoo.com/documentation/17.0/legal/licenses), archived 2026-10-15 (Asia/Shanghai). Re-open it before you rely on any line. This article links no app listing.

The license key in __manifest__.py looks like a dropdown. It is really a promise to every buyer about what they may do with your code after they pay. Most listing mistakes come from treating it as a price tag rather than a contract.

1) Lead answer

1. Community Edition (17, and per the page every version since 9) is LGPLv3. Your module may depend on it under any compatible license.
2. Odoo's own paid apps use the Odoo Proprietary License v1.0 (OPL-1) "unless otherwise stated". OPL-1 allows use and modification only for people who bought a license or got written agreement, and forbids redistributing or selling copies.
3. If your module uses an Enterprise or OPL-1 module as a library, you may still distribute yours under "the license of your choice" if it is compatible. Odoo's own examples: LGPL, MIT, or proprietary licenses similar to OPL. You may not copy source code or material from the OPL module.
4. Picking LGPL-3 for a paid module is allowed, but it is an honest giveaway: a buyer may lawfully share the code. Don't sell it as "protected".
5. Odoo 8 is AGPLv3. Selling a v8 backport under OPL-1 means knowing what you are building on.

2) The two licenses side by side

3) The Enterprise-dependency trap

The Enterprise Edition License says the Software "can only be used ... with a valid Odoo Enterprise Subscription for the correct number of users". If your module depends on an Enterprise module, your buyer needs that subscription too, whatever license your file says.

Honest listing line: "Requires Odoo Enterprise (e.g. ). Does not work on Community." Leave it out and your refund requests are self-inflicted.

Partners get the same rights only "limited to a testing or development environment". Being a partner does not mean your customers can run Enterprise for free.

4) What you may claim, and what you may not

5) Pre-submit self-check

• license key matches the LICENSE file in the repo and the listing text.
• Every dependency listed; Enterprise ones called out in the first screen of the description.
• No copied files or snippets from OPL-1 modules (search your diff for their copyright headers).
• If LGPL-3: the listing does not imply exclusivity.
• If OPL-1: the original copyright notice ships in every copy.
• v8 branches checked separately (AGPLv3).

6) Not verified

• How the Apps Store enforces OPL-1 after purchase.
• Whether Store policy adds anything to LGPL resale rights for paid modules.
• That the 18.0/19.0 doc pages carry identical text (only 17.0 was archived).
• The legal effect in your jurisdiction. Ask a lawyer for that.

7) Bottom line

Choose the license for what you want buyers to be able to do, and write the listing from it. OPL-1 is a contract, not DRM. LGPL-3 on a paid app is generous, and you should say so. Enterprise dependencies are your buyer's cost, so print them up front.

Not legal, tax, or investment advice. Mechanics below come from docs.apify.com (Publish, Set up monetization, Monetize, Pay per event, Actors in Store) and the Store Publishing Terms, archived 2026-10-15 (Asia/Shanghai). Console behaviour changes, so re-open the pages before you change price. This article links none of our products or Actors.

This article is not a Store publishing checklist. Related reading on pricing claims: this guide. Here the only job is: the seam between publishing and monetization — the timing rules that decide when a price takes effect, and how they change how you should launch.

1) Lead answer

1. Monetization sits inside the Publishing tab. You complete Display information, Monetization, Sample output, Output schema, and Actor permissions, then press Publish on Store (Publish).
2. Billing and payment details come first. Set up monetization: “first complete your billing and payment details. Then, you can define the pricing” (Set up monetization). KYC is what payouts need; it is not a step for publishing (Terms §10.1.2–10.1.3).
3. Significant changes (pricing-model change, price increase, new paid event) notify users and take effect after 14 days. During that window the old pricing applies. You can’t cancel or modify a submitted change (support only), you get one per month per Actor, and a pending change blocks new ones (Set up monetization; Terms §9.4).
4. Exemption: “if your Actor has no paying users, the waiting period doesn’t apply and the change takes effect immediately.”
5. Non-significant changes are immediate: price decreases, removing events, description edits, non-pricing settings.
6. The “Pay per event + usage” toggle is asymmetric: turning it on takes 14 days; turning it off is immediate because it is “a positive change for users” (PPE).

2) Order of operations at the seam

Whether Console lets you publish with no monetization section completed (as opposed to choosing pay-per-usage) is Not verified.

3) Significant vs non-significant: the timing table

Worked calendar (hypothetical): submit a price increase on 2026-10-15, and it takes effect 2026-10-29. You can’t submit another significant change while that one is pending. With “once per month per Actor,” plan the next one around mid-November. Whether “month” means a calendar month or a rolling 30 days is Not verified.

Worked profit (hypothetical PPE, 1,000 results, $0.50 platform cost; 80% − costs per Terms §10.2.1): $2/1k gives $1.10 profit and $3/1k gives $1.90. Until day 14 you earn at the old rate, so don’t book the higher number early.

4) Free → paid on an already-published Actor

The docs don’t say “free → paid” in those words. They do define it through the rules above:

• Moving from pay-per-usage (users pay only platform usage) to PPE is a pricing-model change, which makes it significant: users are notified and it takes effect after 14 days.
• Adding a paid event on top of existing PPE is also significant.
• If nobody pays yet, the change is immediate, so the cheapest moment to settle pricing is before paying users show up.
• Free-plan users: if you limit them, say so up front in the README and input schema, exit gracefully with a clear message, and never dress a policy limit up as a bug (Monetize).
• Set-up-monetization warns against “high prices exclusively for users on a free plan.”
• Announcement duty: Apify notifies users of significant changes. The docs don’t say whether creators must post their own notice. Updating the README to match the current price (not the pending one) is the honest default. The exact notification channel is Not verified.
• Rental: since 2026-04-01 you can’t publish new rental Actors or change rental pricing; since 2026-10-01 rental is retired and remaining Actors moved to pay-per-usage (Actors in Store). Don’t plan a “rental → paid” path now.

5) Publish-side rules that bite monetized Actors

From the Store Publishing Terms:

• §2.2.4.2: no promoting off-platform products in the README or description, and no review incentives or self-reviews. You can’t route paid users to an external checkout from the Store page.
• §3.2: Apify may run promotional pricing, coupons, and discounts on your Actor. Don’t promise “price never changes.”
• §7.1 / §10.2.2: a Faulty Actor can be marked under maintenance and deprecated after 30 days. No payout accrues while it is Faulty.
• §8.1: user Issues must be addressed within 14 days, or the Actor can be declared Faulty.
• §9.2: profit and payout figures in the UI are estimates.

6) Seam self-check

1. Billing details done before opening Monetization?
2. Is the first public price the one you can live with? (Before paying users, changes are immediate; after, it’s 14 days and once a month.)
3. No pending significant change you might want to undo? (It can’t be cancelled.)
4. README/input schema state free-plan limits and the current price?
5. Not counting on PPE + usage as a temporary bump? (On takes 14 days, off is instant.)
6. KYC planned so earnings aren’t stuck (12-month forfeit)?
7. No off-platform checkout links on the Store page?

7) Not verified

• Calendar month vs rolling 30 days for “once per month.”
• The channel and wording of Apify’s user notification for significant changes.
• Publishing with no monetization section completed.
• Whether unpublish → republish resets the timing rules.
• Whether a price change made during an Apify-run promotion (§3.2) counts as significant.

Sources (archived)

• Publish your Actor
• Set up Actor monetization
• Monetize Actors
• Pay per event
• Actors in Store
• Apify Store Publishing Terms

Not legal or tax advice. Rules below come from Gumroad Help articles 79, 66, 222, 333 and the Pricing page, archived 2026-10-15 (Asia/Shanghai). Gumroad edits Help often — re-open them before you plan around Discover. This article links none of our products.

This article is not a shallow Discover overview. Here the only job is: the exact switches that put a product on (or off) Discover, what flips them, and where the documentation simply stops.

1) Lead answer

1. Two gates, in order. Account gate: payout settings filled in, ≥ $100 USD balance from genuine sales, then risk-team review (~3 weeks on average after crossing $100). Product gate: ≥1 successful non-refunded sale, a category selected, ratings enabled (79).
2. Discover is on by default once both gates pass. The documented off-switch is deleting the product’s category (79).
3. Hiding ratings also removes you — Help 222: if you toggle ratings off display, “your product will not show up in the Discover search anymore” (222).
4. Discover = flat 30%, processing included; direct = 10% + \(0.50 plus card 2.9% + \)0.30. The $20k/month high-volume discount applies to direct only; “Discover marketplace sales stay at 30%” (66).
5. Discover products are auto-enrolled in Gumroad Affiliates (fixed 10%, 7-day cookie). Opting out is account-wide, not per product (79, 333).
6. Ranking is not public. The only documented lever is “descriptive and specific” tags inside a category. Anything more is Not verified.

2) The switch board

Practical implication: “I hid the two bad reviews” and “I’m on Discover” cannot both be true. If you want Discover, ratings stay visible.

3) Refunds hit Discover twice

From Help 79 + 222:

• Product gate: a refunded sale does not count as the “one successful sale.” If your first and only sale is refunded, the product drops back to ineligible.
• Ratings: a full refund removes that buyer’s rating and excludes it from the average; a partial refund does not (bundles excepted). So refunding to erase a bad rating also erases a qualifying sale.
• Fees: Gumroad returns its own fee on the refunded portion but keeps the processing portion (66).
• Whether refunds that pull the account below $100 re-trigger risk review or remove account eligibility is not documented → Not verified.

Honest reading: don’t use refunds as a ratings-management tool. Use the documented “Respond” to reviews instead (222).

4) What 30% actually costs at small prices (Decimal, tax ignored)

From Help 66 rates; PayPal fees not modelled (Decimal).

The $0.50 fixed fee makes direct relatively expensive at low prices, so Discover’s premium shrinks as price falls. At $9 the premium is $0.74 per sale; at $29 it is $4.16. This is a business call, not an honesty one. But don’t tell yourself Discover is “free traffic.”

Affiliates on top (illustrative only): with fees split pro-rata to commission (66), a $29 sale with a 10% Gumroad Affiliate nets the creator $22.01 at direct rates or $18.27 if the 30% rate applied. Which rate applies when an affiliate link lands on a Discover-listed product is Not verified, so both are shown.

5) Ranking and recommendations: documented vs not

Don’t sell (or buy) “Discover ranking hacks.” The public surface is category + tags + ratings + real sales.

6) Gate-by-gate self-check

1. Payout settings complete? (79)
2. Balance ≥ $100 from real buyers, with no self-buys or household purchases? (79)
3. Clock started for ~3-week risk review; nothing promised publicly until it clears? (79)
4. This product: ≥1 non-refunded sale? (79)
5. Category set, and is it the right one? Tags specific, not stuffed? (79)
6. Ratings visible? (79, 222)
7. OK with automatic Gumroad Affiliates at 10%, or opting out account-wide? (333)
8. Priced with the 30% vs direct gap in mind (section 4)? (66)
9. Warm audience still sent to direct links? (66 fee logic)

7) Not verified

• Discover ranking/recommendation signals beyond tags/category/ratings.
• Numeric meaning of “enough genuine sales” beyond the $100 balance.
• The attribution rule that marks a sale “Discover” versus direct.
• Fee basis for Gumroad-Affiliate-referred sales of Discover products.
• Effect of later refunds/chargebacks on account-level eligibility.
• Help article “Indirect taxes on sales via Gumroad Discover” (not fetched).

Sources (archived)

• Gumroad Discover (79)
• Gumroad’s fees (66)
• Product ratings and reviews (222)
• Affiliates on Gumroad (333)
• Pricing

This article is not a walkthrough of the free-template ladder. Here the only job is: what you can honestly say about paid before vs after verification — and what official pages do not yet promise.

1) Lead answer

1. Anyone can become a creator and share templates on n8n.io (Becoming an n8n template creator…). That is not the same as “I sell paid templates on Creator Hub.”

2. New (unverified) creators: submit one template at a time; next only after the previous is approved. Review usually takes within a week, often sooner (same Help Center FAQ).

3. Verified unlock: after 3 approved templates you become a verified creator. Perks documented by Help Center + Creator Hub: submit up to 4 at a time; creators Discord; verified badge; the option / ability to publish paid templates.

4. Honesty gate: until those 3 approvals (and the paid option is actually available on your Creator Dashboard), do not market “my n8n.io paid template” or “Creator Hub paid listing live.” Say “building free templates toward verification” if you must talk publicly.

5. Program is evolving (Contribute, Use templates): public docs do not publish a paid-template commission %, minimum price, refund policy, or payout calendar. Those numbers are Not verified — do not invent them in listings or tweets.

6. Submission honesty (Template submission guidelines): sticky notes mandatory; no hardcoded API keys; do not plagiarize or resell someone else’s template (ban risk). “Paid” does not license stealing a free community workflow and flipping it.

2) Free → paid — claim ladder

3) Honesty table — paid language self-check

4) What public docs verify vs leave blank

Verified (cite these)

Not verified on public official pages (do not invent)

1. Paid-template commission / revenue share percentage.

2. Paid-template minimum price, currency rules, tax handling.

3. Paid-template refund / chargeback policy and who handles support.

4. Payout method, minimum threshold, and calendar for template sales.

5. Whether unpaid free templates can later be converted to paid (or must be new listings).

6. Ranking / Discover-style traffic rules for paid vs free templates inside n8n’s library.

If the Creator Dashboard shows numbers after you verify, treat the UI + any in-app terms as the source of truth and re-archive them before you publish marketing copy — they were not extractable as stable public Help articles on archive day.

5) Free-period marketing that stays honest

While you are still clearing the three free approvals:

1. Talk about problem → workflow outcome, not imagined paid ARR.

2. State clearly: “Free template submitted to n8n Creator Hub; paid listings require verification (3 approved templates).”

3. Do not gate the Hub-submitted free JSON behind your own checkout while calling it an “n8n free template.”

4. Do not use “n8n Verified” wording until the badge path completes (Help Center even lists “badge hasn’t arrived after third approval” as a reason to email creators@).

5. Keep credentials/PII out of shared JSON — honesty includes operational honesty to importers, not only price honesty.

6) What this article deliberately skips

• Full free-template publish checklist, sticky-note patterns, description template → a separate guide.

• LLM JSON reliability patterns → a separate guide.

• Gumroad Discover thresholds / fees → a separate guide (not substituted here; n8n official gate was sufficient for an honesty piece).

• Third-party marketplace seller terms (FlowMarket, n8nplace, etc.) — not official n8n; out of scope except as “don’t mislabel them.”

7) Not verified (summary)

1. All paid-template economics (fee %, min price, payout, refunds) — not on Help Center / Docs / Hub public pages fetched 2026-10-15.

2. Exact Dashboard UI labels for the paid publish toggle (Notion/Help only say “option / ability to publish paid templates”).

3. Whether verification can be revoked and whether paid listings survive revocation.

4. Interaction between affiliate 30% (partners) and template paid sales — treat as separate unless n8n publishes a combined policy.

Sources (archived)

• https://support.n8n.io/article/becoming-an-n8n-template-creator-and-getting-help

• https://support.n8n.io/article/how-can-i-become-a-verified-template-creator

• https://n8n.notion.site/n8n-Creator-hub-7bd2cbe0fce0449198ecb23ff4a2f76f

• https://n8n.notion.site/Template-submission-guidelines-9959894476734da3b402c90b124b1f77

• https://docs.n8n.io/contribute/

• https://docs.n8n.io/workflows/templates/

This article is not about where money is collected or a pre-submit checklist. Here the only job is: honest free / paid / freemium language that matches Community licenses, selling policies, and review guidelines.

1) Lead answer

1. “Free” on Community is a license statement, not “public domain.” By default, free plugins ship under the Community Free Resource License (copyright & licensing): users may run the plugin in files for any purpose; they may not resell or redistribute the plugin. Creators may supplement or replace that default with their own terms — if you do, say so in the listing.
2. “Paid” on Community uses the Community Paid Resource License (creators may supplement, not wholesale replace, for plugins). Users may run the plugin for any purpose; they may not resell, redistribute, or copy it. Do not invent a custom commercial license that contradicts the Paid Resource License for Community checkout.
3. You cannot sell a file that was already published free. For plugins/widgets, Help Center allows moving some functionality behind a paywall via the Payments API, but the plugin/widget must still contain free features in addition to paid (About selling Community resources).
4. Once a plugin is published paid, it cannot later be converted to free (Publish classic plugins). Do not promise “we’ll make it free after launch” if you already shipped paid.
5. Listing must match reality (Plugin and widget review guidelines): accurate description / screenshots; no hidden functionality; if third-party accounts or additional payments are required, that must be clear in the description. Monetizing via a third party is allowed; monetizing in “poor taste” can be rejected.
6. Custom trials need explicit listing copy (Requiring payment): if you customize free-trial experience (time- or usage-based), the description must clearly explain what’s included and how long (if time-based). Default subscription trial is seven days (About selling); one-time paid plugins have no free trial by default.

2) Free vs paid — honesty table (creator claims)

3) Commercialization limits Community actually documents

From About selling Community resources + Publish classic plugins:

4) Review-guideline language traps (honesty-focused)

From Plugin and widget review guidelines:

1. Accurate descriptions — operate as described; no surprise hidden functionality.
2. External connections clear — third-party account or additional payments / licensing must be clear in the description.
3. Business / monetization — directing users to a third party to monetize is allowed; “poor taste” monetization may be rejected (poor taste boundary is judgmental — exact examples beyond ads / recreating Figma paid AI are Not verified).
4. No ads in plugin UI / files.
5. Do not recreate core Figma / paid Figma capabilities (including certain AI / MCP overlaps listed in the guidelines).
6. Support contact is your responsibility — claim a real channel you will answer (selling terms also expect customer email response within three business days).

5) Payments API / trial honesty checklist

6) What this article deliberately skips

• Figma-native vs Gumroad/third-party rail choice and fee comparison tables → a separate guide.
• Manifest icons, cover sizes, networkAccess labels, desktop/2FA submit prep → a separate guide.
• Country payout eligibility deep lists / W-8BEN fill → a separate guide / tax pieces (do not reopen a separate guide wording here).
• Step-by-step Stripe onboarding screenshots → not here; not published.

7) Not verified

1. Exact internal definition of monetization “in poor taste” beyond the written ads / core-capability / AI overlap rules.
2. Whether any grandfathered exceptions exist for converting paid → free (docs say cannot).
3. Live length of “not approving new creators to sell paid files” freeze (stated on Help page at archive time; plugins/widgets still documented as sellable for eligible creators).
4. Exact intermediary bank fee when cashing out via Stripe (not specified as a fixed USD range on these pages).

Sources (archived)

• https://help.figma.com/hc/en-us/articles/12067637274519-About-selling-Community-resources
• https://help.figma.com/hc/en-us/articles/360039958914-Plugin-and-widget-review-guidelines
• https://help.figma.com/hc/en-us/articles/360042296374-Figma-Community-copyright-and-licensing
• https://help.figma.com/hc/en-us/articles/360042293394-Publish-classic-plugins-to-the-Figma-Community
• https://www.figma.com/legal/community-free-resource-license/
• https://www.figma.com/legal/community-paid-resource-license/
• https://developers.figma.com/docs/plugins/requiring-payment/

This article is not a vendor listing checklist or a multi-series maintenance guide. Here the only job is: when and how Odoo pays you, what “€400” actually gates, what SWIFT wording allows you to promise buyers/partners, and what you must still confirm with Odoo because public docs are silent.

1) Lead answer

1. Split: Odoo S.A. takes 30% commission on Apps Store sales; you receive 70% of module revenues (FAQ, Vendor Guidelines, Submit). IAP (In-App Purchase) is separate: 25% commission on each IAP transaction (FAQ).
2. Accrual: Sales land on a PO (purchase order) visible on your sales dashboard. That PO stays Open until Odoo closes it.
3. Close gate: During each month, Odoo closes POs that have reached or exceeded 400 euros of unredeemed sales (FAQ, Vendor Guidelines). Under €400 → expect the balance to carry, not a weekly wire.
4. Redeem paths:
   • Automatic: enable in Preferences → Odoo pays after close “in the following days” (FAQ) / sends accumulated prior-month amount (Guidelines). Legal check: some countries forbid receiving bank money without issuing an invoice — Guidelines tell you to confirm with local counsel before enabling.
   • Manual: wait for close + notification → send invoice that includes the PO / redeem reference and matching amounts. Do not invoice Open POs.
5. Rail: Payment is international SWIFT. Official wording: may take several days or weeks; delay is higher outside Europe (FAQ, Vendor Guidelines). No published day-count SLA, IBAN field list, or intermediary-fee schedule on these pages → treat specifics as Not verified until Odoo/your bank confirms.
6. FX: Apps are sold in the end user’s currency, so dashboard amounts can deviate from your list currency due to exchange rates (Vendor Guidelines). List currency itself is only EUR or USD in the manifest (Guidelines) — that is pricing, not payout currency documentation (payout currency details → Not verified on public FAQ).

2) Money path diagram (seller self-check)

Buyer pays on Apps Store
        ↓
Sale line appears on your Sales dashboard PO (Open)
        ↓
Month rolls; unredeemed sales on PO ≥ €400?
   no  → keep accruing (no redeem yet)
   yes → Odoo closes PO
        ↓
Auto-redeem ON?  → Odoo processes payment “following days”
Auto-redeem OFF? → email: send invoice with redeem/PO ref + matching totals
        ↓
International SWIFT → your bank (days–weeks; slower outside Europe)

Honesty rule: “I get paid every month” is only true if (a) you cross €400 unredeemed, (b) the PO is closed, and (c) auto-redeem is legal/on or you invoice promptly. Slow months under €400 are carry, not a bug.

3) Commission & threshold — worked example (local Decimal)

Assume a €32.00 list price (EUR). Official split: Odoo 30%, vendor 70%.

€400 close threshold is worded as unredeemed sales on the PO (gross sales tracked), not “vendor net ≥ €400”.

Python Decimal (archived in the archived sources):

So you can clear the close gate while your net is still well under €400. Do not tell partners “Odoo pays when I have earned €400 net.”

IAP: if you use IAP, commission is 25% per FAQ — do not apply the 30% Apps formula to IAP lines without checking the dashboard (line-level IAP arithmetic in UI → Not verified beyond the stated %).

4) Automatic vs manual redeem — honesty table

Sanctions / commission hold: Vendor Guidelines — if apps are under temporary or long-term sanctions, no commissions are paid. Recurrent guideline breaches can unpublish apps and suppress the account. Payout honesty includes “my apps are in good standing.”

5) SWIFT self-check (what public docs allow)

Seller action when docs are thin: treat the checklist in §7 as questions for Odoo support / your accountant — do not fill gaps with forum folklore.

6) What buyers / partners should hear (and not)

Safe (aligned with official pages):

• Store price is subject to 30% platform commission on Apps sales.
• Vendor payout waits on PO close at ≥ €400 unredeemed sales, then SWIFT.
• Support obligations for paid apps remain yours (Guidelines) — payout lag is not an excuse to ignore bugs.

Unsafe:

• “Odoo wires me on the 1st of every month like a salary.”
• “Minimum payout is €400 to me” (threshold is unredeemed sales, not net).
• “SWIFT always clears in three days inside the EU” (docs only say days/weeks; EU not singled out as a fast SLA — only “outside Europe” as slower).
• Quoting a Reddit thread as policy (a separate guide links demand chatter; bodies remain Not verified — do not promote them as payout rules).

7) Seller checklist — verify with Odoo / counsel (public docs stop here)

Mark each row after you confirm live; until then keep the Not verified label in your own runbook:

1. Exact bank detail fields required on the Apps payout / Preferences form (IBAN, BIC, account holder match rules).
2. Payout currency and who bears FX when the PO closed in mixed end-user currencies.
3. Whether intermediary SWIFT fees are deducted from the vendor amount (OUR/SHA/BEN).
4. Whether auto-redeem is lawful in your country without issuing invoices (Guidelines explicitly push this to a lawyer).
5. How IAP 25% lines appear on the same PO vs Apps 30% lines.
6. Interaction between commission suspension (sanctions) and already-closed POs.
7. Tax docs Odoo issues (or does not issue) for your jurisdiction — not described on FAQ/Guidelines archive.

8) What this article deliberately skips

• Manifest price / currency / min 9 EUR, screenshots, scoring, GitHub online-odoo register → a separate guide.
• Porting modules across Odoo series → a separate guide.
• Creating or submitting an Apps listing, registering an account, or sending a real invoice → out of scope (not published; not executed).

9) Not verified

1. Live Sales dashboard PO field names and timezone of “during each month” close jobs.
2. IBAN/BIC / intermediary fee policy.
3. Payout currency and bank-side FX.
4. Exact “following days” count after auto-redeem.
5. IAP line presentation vs Apps lines on one PO.
6. Any non-SWIFT vendor payout option (not mentioned on archived FAQ/Guidelines/Submit).

Sources (archived)

• https://apps.odoo.com/apps/faq
• https://apps.odoo.com/apps/vendor-guidelines
• https://apps.odoo.com/apps/upload

Evidence: the archived sources (sources.md, run.log, html/txt).

This article is not a Store publishing checklist. Here the only job is: what you can honestly claim about how users pay you, how Apify splits revenue, what “rental” still means in 2026, and when money actually leaves Apify.

1) Lead answer

1. Current publishable models on the Monetize index (Monetize Actors): Pay per event (PPE) and Pay per usage. Rental is documented for users still on it, but is being sunset (see #2).
2. PPE creator profit (PPE, pricing & costs, Terms §10.2.1):
   profit = (0.8 × revenue) − platform costs
   You keep 80% of event fees charged to users; Apify keeps 20%; then platform usage for those runs is subtracted from your side (unless you pass usage to users — with transparency / quality-score tradeoffs).
3. Free-plan users do not fund your profit on PPE / rental: only paid-plan customers count toward revenue and cost in the formula (PPE, rental). Apify covers free users’ platform costs in that calc — you still owe them a transparent free-tier story in README / input schema (Monetize).
4. “Pay per result” is not a separate docs page (URL 404 on archive day). Official path for per-result billing is PPE — especially the synthetic event apify-default-dataset-item (charges each pushData to the default dataset) (PPE). Do not invent a third model name in marketing copy.
5. Rental sunset (2026) (rental, Actors in Store): Apr 1 — no new rental Actors / no rental price changes; Oct 1 — rental fully retired; remaining Actors migrated to pay-per-usage. Rental profit was 0.8 × rental fees (paid-plan renters only). Users still pay platform usage on top of the monthly rent — docs call that out as a common confusion source.
6. Payout rails (Manage payouts): billing details + payment method + KYC; invoices issued day 11 for prior month; review days 11–14 (auto-approve 14th if idle); payouts days 21–25. Minimums: $20 PayPal/Wise, $100 other methods; under-min rolls over. Wire is SWIFT from Czech Republic (CZ) with SHA shared fees; intermediary fees often $10–$50 (not a promise — range from docs). UI profit figures are estimates (Terms §9.2).

2) Pricing models — honesty table (creator claims)

Per-result honesty: Say you charge per default-dataset item (or your custom event), not “Apify pay-per-result product” as a separate Store category. Synthetic apify-default-dataset-item is default-on and auto-charges pushData to the default dataset only (PPE).

3) PPE profit — worked example (official numbers)

Docs example (pricing & costs): two paid users generate $31 event revenue and $4 platform cost; free user ignored.

Python Decimal (archived in the archived sources):

Same month, a third free-plan user might show activity in analytics — that slice is not in the profit formula.

Negative profit isolation: if one Actor’s net is negative, Apify treats that Actor as $0 for the month so it does not drag down other Actors’ positive profit (PPE, Manage payouts).

Pass usage to users: “Pay per event + usage” exists to avoid eating platform costs while you tune prices — docs warn it hurts pricing transparency and Actor quality score, and enabling the toggle takes 14 days to take effect (turning it off is immediate) (PPE). Standby runs: users always pay platform usage on top of events.

4) Rental — what not to promise in 2026

From rental / Actors in Store:

Illustrative rental month from docs: one paid renter at $30 → your profit $24 (0.8 × 30). Free-plan trialist who never upgrades contributes $0.

5) Listing / README honesty self-check

6) Payout timing & minimums (creator side)

From Manage payouts + Terms:

Do not promise “payday on the 1st” or “same-week wire everywhere.” Do not promise PayPal is fee-free — docs say PayPal may still charge as the intermediary.

7) What this article deliberately skips

• Store publish sections, README structure, automated tests, quality score deep dive → a separate guide.
• Step-by-step Console screenshots / submitting an Actor → not here; not published.
• Partner Creator special commission contracts → Terms mention them; details Not verified beyond “adjusted structure.”
• Exact intermediary bank fee for your country beyond the documented $10–$50 typical range.

8) Not verified

1. Whether any Console UI still offers a labeled “Pay per result” radio separate from PPE on archive day (standalone docs URL 404; PPE synthetic covers the use case).
2. Partner Creator % schedules (contract-only).
3. Exact calendar day your bank posts a SHA SWIFT (docs: “few additional business days”).
4. Live quality-score weight of “PPE + usage” beyond the qualitative warning.

Sources (archived)

• https://docs.apify.com/actors/publishing/monetize
• https://docs.apify.com/actors/publishing/monetize/pay-per-event
• https://docs.apify.com/actors/publishing/monetize/rental
• https://docs.apify.com/actors/publishing/monetize/pricing-and-costs
• https://docs.apify.com/actors/publishing/monetize/monthly-payouts
• https://docs.apify.com/actors/running/actors-in-store
• https://docs.apify.com/legal/store-publishing-terms-and-conditions

Evidence: the archived sources (sources.md, run.log, html/txt).