MonetizationOS Readiness Questionnaire

Send this to the client’s engineering team before implementation starts. Every answer maps to a line of configuration in the Cloudflare Worker integration guide.

1. Origin & infrastructure

Q1. How does a request reach your site today, from the browser to the server that renders the page? What sits in between (CDNs, proxies, load balancers)?

Why: we’ll place a proxy in front of your site, so we need to understand the request path and whether your servers are publicly reachable.

Q2. How is your infrastructure protected from traffic that does not come through the Cloudflare Worker? How would you prevent someone from bypassing it?

Why: once our layer fronts the site, direct access to your servers would bypass it. We need to know how you will prevent that.

Q3. Where is your DNS managed, and what would a DNS change involve (owners, approvals, freeze windows)?

Why: the integration runs on Cloudflare. If DNS is managed elsewhere, we need a migration plan and timeline.

Q4. Do you use Cloudflare or similar edge tooling on this domain for caching, security, script optimization, or other edge code? Describe what is running and why.

Why: edge features interact and execution order matters. We need to know what the Worker must coexist with.

Q5. Which parts of your site are not normal web pages — APIs, feeds, sitemaps, health checks, streaming endpoints, or static assets? How can we identify them?

Why: these paths must skip paywall processing. The Worker forwards their origin response directly without a MOS surface decision request.

2. Identity & sessions

Q6. How does your site know a user is logged in? Describe what the browser receives after login (cookies, tokens, storage).

Why: we identify signed-in users on every request, so we need to understand your session mechanism.

Q7. Who issues your authentication tokens, and how can a third party verify that a token is genuine?

Why: the integration must independently authenticate the user’s token.

Q8. Once we know who a user is, how do we know what they’re entitled to (subscriber, premium, specific products)? Where does that information live, and how is it kept current?

Why: entitlements drive every paywall decision. Whether they are in the token changes the MOS setup.

Q9. What happens when a user’s session expires, they log out, or their access is revoked — in the browser and in your backend?

Why: we see tokens exactly as the browser sends them, including stale tokens. Expiry and revocation affect MOS surface decisions.

Q10. Do you run multiple sites, subdomains, or brands where the same subscriber should be recognized everywhere? How does that work today?

Why: we need to understand your cookie setup.

Q11. Beyond browser traffic, what else reaches your site — native apps, webviews, partner integrations? How do they authenticate?

Why: non-browser clients often send identity differently, such as in headers instead of cookies. We need to know about them up front.

3. Content & rules

Q12. How can we identify each page’s content type, section, premium tier, and tags? Is that information in the HTML your servers send?

Why: paywall rules can use page metadata added by the origin.

Q13. Is there content where the exact HTML bytes must not change — AMP, signed exchanges, checksummed pages, or similar?

Why: the Worker rewrites HTML. Content with byte-level guarantees breaks if modified and must be excluded before launch.

4. API & platform

Q14. How do you separate staging and production — environments, secrets, and deploy process? How do you prevent credentials crossing environments?

Why: the integration uses one MOS secret key per environment. We need to align with your environment setup.

Sign-off