> For the complete documentation index, see [llms.txt](https://docs.didomi.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didomi.io/consent-management-platform-cmp/introduction/sharing-end-user-consent-with-vendors.md). # Sharing end-user consent with vendors When an end-user provides their consent selections in response to a Didomi consent notice that end-user consent status is transmitted to your organization's vendors in a variety of ways depending on the integrations enabled on the consent notice and/or the vendor type. Review the table below for more information:

Vendor type	End-user consent sharing
IAB vendor	Sharing behavior for an IAB vendor is dependent on whether the consent notice is integrated with the IAB TCF: IAB TCF enabled: End-user consent data is communicated via a standardized consent string (TC string) to the vendor. Vendors will retrieve information through the `__tcfapi` function IAB TCF not enabled: Vendor's tags on your website must execute custom logic that ensures they only trigger when the appropriate consent is received. This custom logic can be managed via your organization's tag management solution (TMS) or by utilizing the custom Didomi script tags to condition the vendor tags on your website so that they only trigger once consent has been collected.
Google ATP vendor	Sharing behavior for a Google ATP vendor is dependent on the kinds of integration(s) enabled for the consent notice: IAB TCF enabled: End-user consent data is communicated via a standardized consent string (TC string) to the vendor. For Google ATP vendors that do not participate with the IAB TCF, Google's Additional Consent string will be communicated. Google Consent Mode: Ensures Google vendors associated with a consent notice comply with an end-user's consent choices (called consent types) defined by Google. Consent information is communicated through modifications in tag configurations and API calls, which may involve Google Tag Manager or direct changes in the website's source code. Click here for more information. No integrations enabled: Vendor's tags on your website must execute custom logic that ensures they only trigger when the appropriate consent is received. This custom logic can be managed via your organization's tag management solution (TMS) or by utilizing the custom Didomi script tags to condition the vendor tags on your website so that they only trigger once consent has been collected.
Global vendor	Regardless of integrations in the consent notice, any global vendor included in a consent notice will need to have its tags on your website execute custom logic that ensures they only trigger when the appropriate consent is received. This custom logic can be managed via your organization's tag management solution (TMS) or by utilizing the custom Didomi script tags to condition the vendor tags on your website so that they only trigger once consent has been collected.
Custom vendor	Regardless of integrations in the consent notice, any custom vendor included in a consent notice will need to have its tags on your website execute custom logic that ensures they only trigger when the appropriate consent is received. This custom logic can be managed via your organization's tag management solution (TMS) or by utilizing the custom Didomi script tags to condition the vendor tags on your website so that they only trigger once consent has been collected.

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.didomi.io/consent-management-platform-cmp/introduction/sharing-end-user-consent-with-vendors.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.