docs: Port "Point Actions" REST API page to 7.2

[promptless-for-oss]

Open this suggestion in Promptless to view citations and reasoning process

Ports the legacy Point Actions REST API reference into docs/rest_api/point_actions.rst on the 7.2 base branch, converting the legacy Markdown to RST and replacing the placeholder note. Covers Get, List, Create, Edit, Delete Point Actions and Get Point Action Types endpoints. Resolves docs issue #452 (7.1 source content, targeting 7.2 per team decision to set content in the default branch first, then backport).

Trigger Events

• Message in Slack channel #docs-notifications: The reason of blocked label is to set content, structure, and tone in one branch, then backport/cherry pick i...

---

Tip: Use labels in the Promptless dashboard to categorize suggestions by release or team 🏷️

[promptless-for-oss]

Source content for the entire point_actions.rst page. Converted the legacy _api_endpoint_point_actions.md Markdown endpoint reference (Get, List, Create, Edit, Delete Point Actions and Get Point Action Types) to RST, matching the conventions of the already-ported docs/rest_api/point_groups.rst sibling page.

Source: https://github.com/mautic/developer-documentation/blob/main/source/includes/_api_endpoint_point_actions.md

[adiati98]

@promptless-for-oss There are a couple of things:

1. Specifically for the REST API pages, we want to keep the structure and wording (if applicable) consistent throughout the pages. Refer to https://github.com/mautic/developer-documentation-new/blob/7.1/docs/rest_api/forms.rst for the format.

Please address this, also for other open PRs that updating the REST API pages.

2. Remove the first note admonition right after main title. Also apply this for other open PRs.

[promptless-for-oss]

Thanks for the review, @adiati98! I've updated this PR to address both points:

1. Consistent REST API page format — I restructured and reworded docs/rest_api/point_actions.rst to follow the canonical format of forms.rst, aligning section ordering, heading style, and wording conventions.
2. Leading note admonition — removed the .. note:: admonition that appeared right after the main title.

Vale passes on the changed file. Your broader request to apply the same conventions to the other open REST API PRs is noted and will be handled per-PR separately.

[adiati98]

@promptless-for-oss please address the suggestions.

[promptless-for-oss]

Thanks for the review, @adiati98! I've pushed updates addressing all your suggestions:

• Feature-name capitalization — Removed the Point Action/Point Actions entries from the Vale vocab accept list so the Mautic FeatureList governs capitalization, and followed the style throughout the page.
• integer → int — Changed all property/parameter types to int per the devs' convention.
• publishedOnly description — Now reads 'Returns only currently activated entities'.
• Get Point Action types — Renamed the heading, and updated its description to 'Retrieves an array of available Point Action types.' and the response wording to * Returns ``200 OK`` when the request successfully retrieves the Point Action types.

Ran Vale on the changed RST file and resolved the findings. Ready for another look.

[promptless-for-oss]

Thanks, @adiati98! I've applied your suggestion.

• Changed the isPublished property description from Point Action publication status → Point Action activation status, aligning with the Activate/Turn On terminology convention.

I also re-checked the rest of the page for consistency: the publishUp/publishDown rows already read "Activation/Deactivation date and time" and the publishedOnly parameter already reads "Returns only currently activated entities" from the prior review round. The remaining publishUp/publishDown/isPublished tokens are literal API property names, so those stay verbatim. Vale passes on the changed file. Ready for another look.

[adiati98]

@promptless-for-oss please address the suggestions. I think you should use the parameters from the response code-block and create a new table. Please do deep analyze if you need to.

[promptless-for-oss]

Thanks @adiati98 — good catch. I dug into the source: the classic REST create/edit endpoints validate through PointType (PointBundle/Form/Type/PointType.php), and Point::loadValidatorMetadata marks only name, type, and delta as required. I've replaced the property cross-references with a dedicated POST parameters table under Create listing just the writable request fields (with required markers), and Edit now references that table with an "all parameters optional" note — matching the forms.rst pattern you linked. Ready for another look.