Feature request Please add a minimal, backward-compatible media indicator to Google Business review objects so API consumers can detect whether a review contains zero, one, or multiple photos attached directly to the review. We do not need access to the images themselves. Proposed fields { "hasPhotos": true, "photoCount": 2 } Expected semantics photoCount An integer, nullable when the exact count is unavailable. 0 = no photos attached to the review 1 = exactly one photo attached to the review greater than 1 = multiple photos attached to the review null = at least one photo is confirmed, but the exact count is unavailable Please do not return an estimated or potentially incorrect count. hasPhotos A boolean indicating whether at least one review-attached photo is confirmed. When the exact count is known: hasPhotos === (photoCount > 0) If the exact count cannot be exposed initially, a reliable hasPhotos boolean alone would already be very useful as a first phase. Important distinction The reviewer’s profile picture must never be counted. This request concerns only photos attached directly to the Google review, not: reviewer.profileImage the business logo business media avatars unrelated media API surfaces Please expose the fields on Google Business review objects returned by: GET /v1/inbox/reviews?platform=googlebusiness&accountId=... Ideally, include the same fields in: review.new webhook payloads review.updated webhook payloads This would allow automations to react immediately without additional polling. Explicit non-goals We are not requesting: image URLs thumbnails image binaries image content OCR image labels or descriptions EXIF metadata visual analysis Only the confirmed presence and, when available, the number of review-attached photos are needed. Use case Our application generates personalized replies to Google reviews. For positive reviews, this metadata would allow safe wording such as: photoCount = 0 → do not mention photos photoCount = 1 → thank the customer for “this lovely photo” photoCount > 1 → thank the customer for “these lovely photos” hasPhotos = true and photoCount = null → use neutral wording that does not assume singular or plural The automation would never describe the photo content. It would only mention photos for positive reviews, typically 4 or 5 stars. Suggested phased implementation Phase 1 Expose: { "hasPhotos": true } A reliable boolean alone already unlocks the main use case. Phase 2 Add: { "photoCount": 2 } This allows correct singular/plural wording. Compatibility This would be a non-breaking addition for existing consumers. For platforms other than Google Business, the fields could be: omitted; returned as null; or consistently returned as hasPhotos: false and photoCount: 0. Any approach is acceptable as long as it is documented consistently. Why this matters This small metadata addition would significantly improve the personalization and natural quality of automated Google review replies without exposing any image data or increasing privacy risk. We would also be happy to beta test the feature as soon as an early version is available.

AKA PREEM 1 day ago

When Zernio loads the inbox when we connect our social media profiles (example: Instagram), it doesn't pull profile photos as ManyChat does. It would be a great function if we could actually see their profile photos in the inbox.

Christian Kadivec 1 day ago

Feature request multiple DM messages & comment replies (random rotation) in Comment-to-DM Hi Zernio team, I'm using the Comment-to-DM automation via the API (createCommentAutomation), and it works great. One request: Right now dmMessage and commentReply each accept only a single string, so every comment on a post gets the exact same DM and the exact same public reply. This looks repetitive and may increase spam-detection risk on Instagram. Could you support multiple messages with random rotation? Allow dmMessage and commentReply to accept an array of strings (e.g. 3–5 variations). For each triggered comment, the system picks one at random. This would let each commenter receive a slightly different DM/reply, making the automation feel natural and reducing the chance of being flagged. Many similar tools already do this, so it would be a big help. Thank you!

션 2 days ago

The Conversions API has createConversionDestination for LinkedIn — you can create the conversion rules a customer needs with one call, making conversion onboarding fully programmatic. Google has no equivalent, even though Google has the same requirement: sendConversions can only deliver into a pre-existing conversion action of type UPLOAD_CLICKS (Google: create conversion actions (https://developers.google.com/google-ads/api/docs/conversions/create-conversion-actions)), and ad accounts don't come with one. Today that means every end customer must manually create conversion actions inside Google Ads (picking type, category, primary/secondary, counting) before anything sent via Zernio can land. For platforms building on Zernio, it's the one manual step left in an otherwise fully API-driven flow — LinkedIn proves how clean the automated version is. Proposed endpoint POST createConversionDestination on a googleads SocialAccount — same shape as the LinkedIn variant, backed by Google's ConversionActionService.MutateConversionActions. Minimal body: ┌────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Field │ Notes │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ name │ string; Google enforces per-account uniqueness │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ category │ Google's ConversionActionCategory enum (https://developers.google.com/google-ads/api/reference/rpc/v24/ConversionActionCategoryEnum.ConversionActionCategory) (e.g. PURCHASE, SUBSCRIBE_PAID, SIGNUP, IMPORTED_LEAD, BOOK_APPOINTMENT) │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ primaryForGoal │ boolean — must be settable and reliably honored. Google defaults it to true (field reference (https://developers.google.com/google-ads/api/fields/v24/conversion_action)), and a primary action immediately affects the advertiser's Smart Bidding │ │ │ (primary vs. secondary (https://support.google.com/google-ads/answer/11461796)). Tools need false (record-only) as the safe create state. │ ├────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ countingType │ MANY_PER_CLICK / ONE_PER_CLICK (counting guidance (https://support.google.com/google-ads/answer/3438531)) │ └────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ type is always UPLOAD_CLICKS (immutable at creation). Everything else — value settings, attribution windows — can stay at Google's defaults. Response: the created destination's id (conversion-action resource name), matching what listConversionDestinations already returns. Two error passthroughs that make it integration-safe DUPLICATE_NAME surfaced distinctly → callers can treat "already exists" as success and reuse (this is also what makes the endpoint naturally idempotent — Google enforces unique names server-side) TOO_RECENT_CONVERSION_ACTION surfaced distinctly → Google rejects uploads for ~6 hours after an action is created; callers need to recognize it as retryable, not a hard failure (troubleshooting doc (https://developers.google.com/google-ads/api/docs/conversions/troubleshooting)) One implementation note For accounts using cross-account (manager-level) conversion tracking, the action must be created in the conversion customer (customer.conversion_tracking_setting), not necessarily the connected account — same resolution the upload path already does. Why it's broadly useful Anyone using Zernio to send Google conversions hits this wall — the send side is fully programmatic, but the receiving object requires end-customer clicks inside Google Ads. This single endpoint closes the loop and brings Google to the same zero-touch onboarding the LinkedIn API already delivers.

Dev 3 days ago

1

I don’t know if anyone has asked yet, but it would be really neat if we could use a custom domain and white label the dashboard experience. I don’t mind references to Zernio present at all either like a footer with “powered by zernio” and the tos/privacypolicy and what not but it would help the dashboard feel more brand aligned at the same time! Might be a nice feature

Dalek 4 days ago

To understand video performance, 3 second 5 second, 20 second, I’d like to see the retention graph per video per platform. So I could improve and make better content. Currently it's only in each platforms analytics deepdives.

Prince Freddie 4 days ago

Be able to edit content of reddit comments posted via API

Kaushik Mahorker 4 days ago

And we will never leave Zernio for Customer Support :)

Lucas Sánchez 8 days ago

Hi Zernio team, We are evaluating campaign / affiliate attribution across Instagram, Facebook Messenger, and WhatsApp conversations through Zernio. Our main use case: Influencers and partners share links that open a conversation with our bot/account. We need to attribute the first conversation/signup to the correct campaign or affiliate code. Instagram Meta natively supports ig.me referral links: https://ig.me/m/?ref= According to Meta’s Instagram Messaging webhook shape, this can produce a messaging_referral / OPEN_THREAD referral payload: referral: { ref: "", source: "", type: "OPEN_THREAD" } We tested this with Zernio: https://ig.me/m/selenagomez?ref=test_ref Zernio only sent us a normal message.received webhook with message, sender, conversation, and account data. There was no referral/ref/metadata field. Request: Can Zernio subscribe to and forward Instagram messaging_referral events, or include the native Meta referral object in the first message.received / conversation.started webhook? Facebook Messenger Meta also supports m.me referral links: https://m.me/?ref= Request: Does Zernio currently forward the Messenger referral/ref object for m.me links? If not, can this be added in the same normalized shape as Instagram? WhatsApp For Click-to-WhatsApp ads, Zernio already documents automatic ctwa_clid capture on the first inbound message and stores it in conversation metadata. That is great. Questions: Is similar first-touch referral metadata available for organic WhatsApp links, or only for CTWA ads? For wa.me links with prefilled text, does Zernio expose the first message text normally so we can parse a campaign code manually? Suggested normalized webhook shape For Instagram and Facebook, ideally Zernio would expose: { "event": "messaging.referral", "platform": "instagram" | "facebook", "account": { ... }, "conversation": { ... }, "sender": { ... }, "referral": { "ref": "", "source": "SHORTLINK", "type": "OPEN_THREAD" } } Alternatively, including the same referral object inside the first message.received or conversation.started webhook would also work. Why this matters Without referral/ref forwarding, affiliate and influencer attribution for messaging entry links is impossible through Zernio. We have to use an intermediate web redirect and fallback promo codes, which is less reliable for mobile Instagram/Facebook flows. This feature would be valuable for: influencer attribution affiliate tracking campaign analytics conversion tracking from messaging conversations first-touch lead source attribution Could you confirm what is currently supported per platform and whether forwarding Meta’s native referral events is on the roadmap? Thanks!

Alexander Sakharov 9 days ago

An integration for posting on KakaoTalk’s new short form feature would be super helpful here in Korea!!!

Korea Seoul South Mission Office 10 days ago

If you integrated sites like Yelp, Bing Places, Apple Maps, TripAdvisor, Foursquare, BBB, YellowPages, MapQuest etc you could extend your offering to be used to for business listing management. Just sayin’

James Taylor 12 days ago

I'd love to see a one-time lifetime buyout for the Inbox add-on — pay once, keep it permanently — instead of only the recurring monthly option. To be clear, I'm asking for a perpetual license, not a monthly discount. For context: I'm an AppSumo Tier 4 customer and already have Analytics on lifetime. Inbox is currently the only add-on without a lifetime/buyout path. I'd suggest looking at this as net-new revenue rather than lost revenue. A big part of the AppSumo base came in specifically for the lifetime model, and for that group a recurring add-on is a non-starter on principle — so today Inbox earns nothing from us. A one-time buyout doesn't undercut your monthly subscribers (it's a different buyer entirely); it turns people who currently pay zero into paying customers. You could even set it at a premium one-time price and it's still revenue you aren't capturing today. As a bonus, it keeps the AppSumo cohort engaged, which tends to show up in reviews and retention. So — any chance of a one-time lifetime buyout / perpetual license for Inbox, at least for existing AppSumo lifetime customers? If you're another AppSumo user who'd want this too, please upvote and add a comment so the team can see the real demand.

Alex Khan 14 days ago

2

Good afternoon, I wanted to propose adding the reception of incoming messages to the market via webhook in order to automate them, thank you.

Pablo Castañeda 18 days ago

1

Zerino seems to have everything in place, but only one feature is missing. “Live scheduling” or “ RTMPS stream key via API” for Instagram, Facebook, and others. This could be a key factor for many businesses like us to fully rely on Zerino or explore other platforms

Hadi Alavi 19 days ago

It would be able to post the audio of a YouTube video to Spotify when the YouTube video launches. Basically just support Spotify as a posting system.

Zac Clifton 21 days ago

1

Would be really nice if we could add media to the post by dragging and dropping them into the post! Also would love it if adding media did not remove previously uploaded media. Sometimes I pick media from different locations on my pc and find the fact that it replaces the first image tedious 🙏

Dalek 22 days ago

It would be nice to have dev.to as provider for scheduling posts with support for organizations.

Robin Genz 28 days ago

We'll be good if you can try to get Meta to eventually support Facebook professional profiles in their API https://www.facebook.com/business/help/2680340558863560

chazrt about 1 month ago

Hi Zernio team, We are building an AI-powered advertising platform and using Zernio as our execution layer for Meta Ads via BOBO. We would like to request support for a simplified “budget + fee split” workflow for BOBO-based ad execution. Use case Our system: Generates ad creative (video + copy + link) Requests a total campaign budget from the client Splits the budget internally: 25% platform fee 75% Meta ad spend Launches ads via Zernio using BOBO (on behalf of client) Retrieves performance data via Zernio analytics layer Feature request We would like Zernio to support or expose: Clear BOBO execution for ad creation under client accounts Ability to pass a single “total budget” input while allowing internal allocation logic at the platform level Or at minimum, ensure Zernio does not constrain downstream budget handling logic when using Meta BOBO ad accounts Why this matters This enables a new category of AI-driven “done-for-you advertising” products where: users don’t manage Meta Ads directly campaigns are generated and deployed automatically platforms like ours can earn from the advertising budget on the backend. Happy to clarify or provide deeper product specs. Thanks in advance! Camilo@infinitecreator.com

Camilo Lopez about 1 month ago