What is Edge Content Protection?
Edge Content Protection (ECP) runs at Arc’s edge nodes and manipulates incoming request URLs before content is served by the CDN or PageBuilder. Rather than blocking unauthorized users, it routes requests to different PageBuilder templates by appending a variant query parameter to the URL. This lets you deliver multiple reader experiences — such as ad-supported, subscriber, or premium — from the same URL.
How ECP Differs from Arc’s Server-Side Paywall
| Arc server-side paywall | ECP | |
|---|---|---|
| Enforcement model | Blocks or allows the request | Routes the request to a specific PageBuilder template variant |
| Entitlement cookie | One of two allowed values, applied across the entire site | A JWT you issue, containing a comma-separated list of arbitrary entitlement strings |
| Rules scope | Site-wide | Per-URL pattern matching with include/exclude paths and a priority-ordered rules document |
| Reader experiences | Binary: authorized or unauthorized | Unlimited: any number of distinct experiences per URL |
| PageBuilder integration | Works with standard resolvers | Requires resolvers configured to handle the variant query parameter |
Key Concepts
Path Include and Exclude Patterns
ECP uses path include/exclude patterns to determine whether it processes a request at all — before any cookie or JWT handling occurs.
- Include paths: if configured, only requests whose path matches at least one pattern are processed; all others are forwarded as-is without a
variantparameter. - Exclude paths: requests whose path matches any exclude pattern are forwarded as-is without a
variantparameter, bypassing ECP entirely.
Patterns are ;-separated and support * and ? wildcards.
Reader Experiences and Variants
You can configure multiple PageBuilder templates that render the same content differently. For example:
- An anonymous user might see a page with ads and a limited article preview.
- A subscriber might see the full article without ads.
- A premium subscriber might see the full article with exclusive content.
ECP selects the correct template by appending a variant query parameter to the request URL (for example, ?variant=premium). PageBuilder resolvers read this parameter and render the appropriate template.
JWT Entitlement Cookie
You set a cookie in your own external system. The cookie value is a signed JWT (HS256 or HS512) that contains the reader’s entitlements. ECP validates this JWT at the edge and uses two claims to determine the variant:
| Claim | Required | Description |
|---|---|---|
entitlements | Yes | Comma-separated list of entitlement strings (e.g., "sports_no_ads,premium") |
prepend | No | A string prepended to the variant value before it is appended to the URL |
exp | Yes | Standard JWT expiration timestamp; validated by ECP |
Rules Document
You upload a JSON rules document in the Delivery admin UI. The rules engine evaluates each rule in priority order against the incoming request URL and the entitlements claim. The first rule that matches both determines the variant value. If no rule matches, the request is forwarded without a variant parameter and PageBuilder renders the default template.
Variant Construction
The final variant query parameter value is assembled as:
variant = <prepend claim value> + <resolver-query-param from matching rule>If the prepend claim is absent, only the resolver-query-param value is used.
PageBuilder Integration
ECP works closely with PageBuilder resolvers. Resolvers must be configured to read the variant query parameter and select the appropriate template.
For more information, see Configuring resolvers.
Cost Considerations
Each unique variant value results in a separately cached render in PageBuilder. To optimize rendering costs, design your rules and prepend values to minimize the number of unique variants.