Dynamics Community Forum Thread Details

Officially supported way to trigger a headless CIJ Form Submission with DOI from a backend?

Hi everyone,

I'm looking for guidance on a CIJ scenario where the standard documented integration patterns don't seem to fit.

Scenario: We have a website where unknown visitors can register / sign up. The registration data needs to flow into Customer Insights – Journeys so that:

A form submission is created in CIJ
The standard double opt-in mechanism is triggered automatically
No contact is created before DOI confirmation (GDPR requirement)
After confirmation, a follow-up journey starts

Constraints:

We cannot embed anything in the frontend of the website (no Microsoft form embed, no JavaScript snippet, no Form Capture). The API request the frontend sends, however, can be adjusted.
We want to stay as close to Microsoft standard as possible – ideally not rebuild the DOI logic ourselves via Power Automate.
The person is initially unknown in Dynamics – no contact / lead exists yet.

Open questions:

Is there an officially supported, server-side way to push form submission data into CIJ from a backend system (e.g. via API gateway / middleware), so that the standard DOI mechanism kicks in?
The form submission endpoint exposed by published marketing forms seems to use the following pattern: https://{server}.dynamics.com/api/v1.0/orgs/{orgid}/landingpageforms/forms/{formid}.

Is this endpoint intended for backend-to-backend use, or is it strictly meant for the form capture / embedded form scenario? Is there official documentation for direct backend invocation?
If neither path is supported: what is Microsoft's recommended pattern for "headless" registration flows that need to honor DOI before contact creation?

Any pointers to documentation, blog posts, or official guidance would be highly appreciated.

Thanks!

Hi JE-04050955-0,

1) Issue
- There is a requirement to submit registration data from a backend system into Customer Insights Journeys so that a form submission is created
- The standard double opt-in process must be triggered automatically
- No contact or lead should be created before DOI confirmation due to GDPR requirements
- Frontend integration options such as embedded forms, JavaScript, or form capture cannot be used
- It is unclear whether the CIJ form submission endpoint can be used for server-to-server communication

2) Reason
- The Customer Insights Journeys form submission endpoints are primarily designed for browser-based scenarios such as embedded forms or form capture scripts
- These endpoints rely on client-side context such as cookies, tracking identifiers, and session metadata which are not naturally present in backend-to-backend calls
- There is no officially documented or supported API specifically intended for headless server-side form submission that triggers full CIJ behavior including DOI
- The DOI mechanism is tightly coupled with the marketing form infrastructure, including submission tracking and consent management
- As a result, directly calling the endpoint from a backend system may work technically in some cases but is not supported and can lead to inconsistent behavior or compliance risks

3) Resolution
- Use the standard CIJ marketing forms wherever possible, as they are the only officially supported way to trigger DOI correctly
- If frontend embedding is not possible, implement a lightweight proxy approach where the backend passes data to a minimal frontend layer that submits the form using the supported mechanism
- Alternatively, create contacts or leads in a staging state via backend integration and trigger DOI using a custom journey, ensuring no marketing consent is applied until confirmation
- Use real-time journeys with triggers based on Dataverse events to replicate DOI behavior in a controlled and compliant way
- Store incoming registrations in a custom entity first and only create contacts after DOI confirmation is completed
- Avoid direct backend calls to the landing page form endpoint unless explicitly validated, as this is not an officially supported integration pattern
- Follow a compliant architecture where consent capture and DOI logic are explicitly designed, even if it requires partial custom implementation instead of relying fully on out-of-the-box form behavior
- Review Microsoft guidance on consent and marketing forms to ensure GDPR compliance when implementing custom or semi-custom solutions

For a more detailed answer, please provide more information.

Rg,

Alexander

*Due to the complex and different possibilities of deploying Dynamics 365 I highly recommend not to setup the application without some expert/partner or support. (For more information contact me under anassl@inno-solutions.info or visit www.inno-solutions.de)

*The Information comes directly from the manufacturer or provider and are validated (not guaranteed) up to date of creation of the posting.

References: