Does the inline <style> WAF rule apply to PATCH, and what is the canonical success signal?

[ang-var]

Hi — writing from Asbury Automotive Group. We integrate with the page creation API and have two questions the current docs don't settle. Happy to move either of these to our existing email thread with the Dealer.com team if that's preferable, but the README points here for API questions.

1. Does the inline <style> WAF rule apply to PATCH as well as POST?

We're finishing work to stop emitting inline <style> elements in the HTML we post, ahead of the WAF rule being locked down. The guidance we've had so far is that already-published pages are fine to leave, and that new pages would be blocked if their content contains inline <style> tags.

What we'd like to confirm is whether that phrasing covers creates only, or creates and updates both:

• Does the rule inspect the body of PATCH /api/v1/pages the same way it inspects POST /api/v1/pages?
• Does the current exception cover both verbs?

This matters a lot on our side because roughly 97% of our API traffic is PATCH updates rather than POST creates. If updates are in scope for the rule, then locking it before we ship halts essentially our entire pipeline rather than a small slice of it, so we'd want to sequence carefully. If updates are out of scope, our exposure is much narrower than we've been planning for.

2. What is the canonical success signal on create and update?

The docs give these response codes:

Code	Use	Content
201	Success	{ url: "{domain}/your-created-page.htm" }
206	Partial Content Success	{ url: "...", message: "Page created but there was an issue saving the following: <issueEncountered>" }

In practice we see success responses whose message contains the string Success ::, which doesn't appear in the docs at all. So:

• Is Success :: a stable part of the contract, or an implementation detail we shouldn't depend on?
• Is status code alone sufficient to determine success — i.e. can we treat any 2xx as "the page exists," with 206 specifically meaning "created, content not saved, retry via PATCH"?
• For a 206, is the url in the response always safe to use as the PATCH target?

We ask because we periodically see there was an issue saving the following property: content, which looks like the documented 206 case, and we want to handle it the way you intend rather than treating it as a hard failure.

Minor

release-notes.md ends at 12/2023 and the README still carries two TODO placeholders (getting started guide, retry examples). If there have been contract changes since — response shapes, limits, new endpoints — is there a newer source we should be reading instead of this repo?

Thanks.