Les grands esprits se rencontrent

During the course of implementing our own "Communication Preferences" page as part on an on-boarding process, we encountered (during testing) the problem of not being able to resubscribe to a subscription type if it had been previously unsubscribed.   The API documentation includes this:   Subscribe contact The subscribe contact endpoint allows you to subscribe an email address to any given subscription type in an account, but will not allow you to resubscribe contacts who have opted out.  Example use case: This endpoint is ideal for when you have an integration or external form that needs to opt contacts into a subscription type.  Note: The subscribe contact endpoint should only be used to honor requests from contacts who have given you permission to subscribe them. Please review applicable laws and regulations before resubscribing a contact.   The first part (in bold) does say "will not allow", but then the note ends with "…before resubscribing a contact." I initially interpretted this to mean a global "opt out" or why would there be any talk of "resubscribing" at all.   While the initial on-boarding process won't be directly impacted as they have certainly never been subscribed so leaving any (or even all) of the subscription types unselected simply means they are not subscribed — which isn't the same as having unsubscribed. This will definitely become a problem over time for those who wish to tweak their subscription preferences from time-to-time.   I've read the many posts that lament this situation and there seems to be many who want some kind of solution. I'm creating this new post to outline several potential improvements.   A. Track whether an unsubscribe was via the API and allow resubscribe via API   B. If a subscribe request via API is declined (whether due to previous unsubscribe or a global opt-out), return a link to the HubSpot preferences page in the response which could be presented to the user. (Thus saving the steps/hassle of having/finding an existing email.)   C. Provide an API call to obtain the link to the HubSpot preferences page.   D. Provide a simple way (API or link?) to cause an email containing the link to the HubSpot preferences page to be sent. (I realize that this might not be feasible for a global opt-out because they probably can't be sent an email.)   In case it isn't obvious, these are listed in my preferred order. I am already leveraging the fact that the legalBasis being null means that a "subscribe" is possible so I can at least indicate on our own "Communication Preferences" page that a particular subscription cannot be "resubscribed", but without at least one of the options above the most we'll be able to do is provide a page of instruction on how to overcome an unsubscribe that is later regretted. ... Afficher plus

Hi!   I am considering automating the creation of a Company/Contact via CRM API.   I know that can create Company and Contact via API, but I cannot assign Owners to them. Of course, when I choose to use Workflow (within Sales Professional Plan), it can be possible. But since I am creating Company and Contact via API, why don't I would like to complete everything there? Can HubSpot please consider providing such an interface to assign or update the Owner of the Company or Contact?   The original discussion was triggered by the following thread. https://community.hubspot.com/t5/APIs-Integrations/Create-User-Profile-Assign-Update-Company-Owner-Via-API/m-p/444017#M44009 ... Afficher plus

Buenos días chicos,   Como algunos ya sabréis, los anuncios en Tik Tok cada vez se están haciendo más fuertes.   Hemos estado probando su plataforma publicitaria y se asemeja mucho a Facebook, incluso dejandote crear formularios inside dentro de la plataforma.   A la hora de conectar cuentas de anuncios al CRM, solo están disponibles Facebook, Goolge y Linkedin.   Mi pregunta es, se podrá conectar la cuenta de anuncios de Tik Tok al CRM proximamente? Los desarrolladores de Hubspot están trabajando en ello?   Muchisimas gracias! ... Afficher plus

Hello,   I'm aware this was answered before here   However, I find the resolution of that issue is not satisfying. The padding applied on the iframes by default only makes the result uglier. Being a "React" component doesn't really prevent this from being considered or implemented. If anything it should make it easier.   Here is an example from our work in progress, since we have different banners and a custom background patterns, it looks horrible with this padding.     From a design standpoint, the content should control its own padding and not the parent component. Because there is no way it works for all types of content. Leaving the padding decision to the content is a much better experience and developers can adjust to that better than adjusting to the current behavior.     So please, is there a way we can do this? if not can it be considered? ... Afficher plus

To be as secure as possible, I have crafted the least-permissible Content-Security-Policy (CSP) to work with our website. Of course to run HubSpot integration there are some servers to include from whence hubspot draws it's script and style content - all well and good.   However, this whole process uses _inline_ scripts and styles which our CSP now needs to allow; and it would be more secure to not allow inline scripts and styles.   Ideally, Hubspot would simply deliver this content as small resources (js or css files) instead of writing the content inline, then I'd not have to add it. For more info about why I'd rather not have it see here - https://content-security-policy.com/unsafe-inline/   For right now, I will probably add hashes for the inline content, but I'll need to experiment because it's possible that the content changes - perhaps even likely given that it has been chosen to not deliver it as a resource. ... Afficher plus

Hello Community! 🙂   There appears to be a couple of oversights present in both the public app marketplace's application form, located in the 'Pricing' section as well as the listing copy in the same section for published apps.   App application form   1) Pay-as-you-go pricing is limited to whole cents only. Many API products are priced per API call, and many have fractional cent pricing, e.g. $0.009, you can circumvent this frontend field limitation by stating for example that $0.90 is per 100 API calls, but for accuracy sakes when a HubSpot customer compares this to the app partners own pricing page it should match. This creates a discrepancy between the HubSpot app listing pricing and the app partners web page pricing. Please enable a few extra decimal places in the pricing fields.    2) 'Contact us' as a pricing tier once selected requires mandatory selections of 'Starts from' and 'Frequency'. If 'Contact us' is selected then it is a stand alone statement, the app partner should not be forced to enter a price from or a frequency (which just so happens to only offer 'One time', 'Monthly' & 'Yearly'... counter intuitive to the pay-as-you-go options.). Please disable mandatory selection of 'Starts from' and 'Frequency' when selecting Contact us as a pricing tier.   App published listing copy   1) When the app is published, the copy should not reference subscription pricing models when the app's pricing is pay-as-you-go. There is a huge difference between the two pricing models and this confuses HubSpot users when we offer the more popular pay-as-you-go but the listing copy mentions subscriptions.   Two locations, in the main pricing section -     and on the upper right side snippet -     The listing application clearly gives you the option to differentiate between the two pricing models, but this is not reflected in the actual listings copy -     Please replace 'subscription' highlighted in screen shots with 'pricing' or reflect the apps selected pricing model option as per above.     2) The app listings copy would flow a lot better if words weren't breaking over lines -     Try using non breaking spaces or nowrap.     Regards, Alexander ... Afficher plus