Verified purchaser
Doesn't work with Common Apps - Support Non-existent for Some Things
I was really excited about Albato at first—its interface is clean, the automation possibilities look great, and the idea of streamlining my workflow sounded perfect. Unfortunately, the reality falls short because it just doesn’t integrate with the tools I actually use.
One of my go-to apps is has no native integration. I saw a feature request it posted over nine months ago on their request‑feature page, and there’s still no update or response. The only workaround is to use an HTTP, which is clunky, confusing, and ultimately didn't work at all.
When I reached out to Albato support to explain the issue, the reply was simply to point me to Hiro's documentation - when I told them that my assistant and worked on this for 6 hours yesterday (don't ask why) and that it still didn't work even with the documentation they provided from their site the response was: “I’m sorry for your frustration.” No apology for the poor instructions, lack of support despite this being a common thing users have to do, no acknowledgment that following the API docs from both Hiro.fm and Albato’s automation doesn’t actually work despite following instructions, and no indication that they’re planning to add Hiro.fm support.
They even told me they don’t offer support for this "custom" automation at all. I'm sure this isn't the only app that they don't support that you have to use this workaround for, so to give zero support is kind of ridiculous.
Albato looks great on paper, but the functionality isn’t ready for real‑world use. Unless someone can help me get a pretty basic automation that works flawlessly in Zapier working - or they add it soon, this app is pretty much useless for me and for any apps that don't have API integration, it's a pain.
----
UPDATE: After this review Albato Support responded and it was a REAL issue with the set up of HTTP (for apps that don't have API Integration) They were able to resolve my issue. Dropping my additional feedback here. TL:DR - gorgeous interface, automations work pretty flawlessly with API, but HTTP is not intuitive...and there are a few sticky issues with choosing products, with Thrivecart, specifically.
---
The platform does work. The AppSumo deal is real — 45,000 ops/month and unlimited automations for a one-time fee is legitimately strong. Once the automation was correctly configured, it ran cleanly and consistently. The core architecture (trigger → filter → action) makes sense and the ops tracking is accurate.
What I found:
The documentation does not match the actual UI. Albato's own wiki on the incoming data filter showed instructions that, when followed exactly, caused the filter to fail every single time. The documentation described placing a dynamic field chip into the comparison value — but Albato's filter silently rejects any run where the value field contains a chip rather than plain text. Following the official docs broke the automation. The correct behavior had to be discovered through trial, error, and platform inspection.
Filter failures are logged as "Success." When the incoming data filter blocks an automation run, Albato marks it as Success in the history log. The message buried in the detail is: "The automation executed, but the data didn't meet the filter conditions." This is misleading at best. A filtered run is not a success — it is a non-execution. Labeling it "Filtered" or "Skipped" would tell users immediately what happened. Calling it Success caused repeated confusion about whether the automation was working or not.
The HTTP Request step requires API knowledge that is not disclosed upfront. When you need to connect to an app that doesn't have a native Albato connector, you use the HTTP Request (Outgoing Webhook) step. Albato does not tell you that this step requires you to know:
The correct API endpoint
The correct request method
The exact field names the API expects
The correct Content-Type header (application/json vs. application/x-www-form-urlencoded — using the wrong one produces a 400 error with no explanation)
That the Authorization header must be manually added — the connection does not handle authentication automatically
None of this is explained anywhere. If you don't already know how REST APIs work, this step is not functional for you without outside help.
The platform works, and the AppSumo deal is worth it if you are migrating standard app-to-app automations. The ops allowance alone MORE than justifies the lifetime price. The platform works, and the AppSumo deal is worth it if you are migrating standard app-to-app automations. The ops allowance alone justifies the lifetime price. But if your workflows require HTTP Request steps — connecting to APIs without native Albato connectors for a steep learning curve that they technically don't support. What should have been a quick setup took 10 hrs , required 41 test purchases, and was ultimately solved by using AI to figure out what the documentation should have said.
Wenddy_Albato
Edited Jun 11, 2026Hi Staci,
Once again, thank you for your understanding and for your valuable feedback.
We’re happy to hear that your automation is now working. In this particular case, the issue was related to the documentation of the external app you were trying to connect, which unfortunately is something outside of our control.
I would like to take this opportunity to provide a more detailed response regarding the other points you mentioned, so we can ensure you have the best possible experience using Albato and that together we can achieve the results you expect.
Regarding the documentation, we believe you may be referring to this article:
https://albato.com/en/wiki/articles/incoming-data-filter
In this article, we explain how to work with filters in your automation. Although it does not explicitly mention that a dynamic value should be selected, we understand that the current explanation may lead to confusion.
We will update the article to reflect the exact configuration process required for this step.
Regarding the success message, Albato considers the trigger execution itself as the success condition. In other words, the event occurred in the external application and successfully reached our platform.
The filter is an internal condition applied after the trigger. Because of this, the message remains associated with a successful execution.
From this perspective, if the data does not pass through the filter, it means the condition you configured worked exactly as intended.
Therefore, it is not considered an error but rather a successful execution of both the automation and the filter logic.
An actual error would involve situations such as connection failures, limitations of the external application, or temporary instability either on the external platform or within Albato itself.
We understand this can be confusing, and we apologize for that. If you need any clarification on this topic or anything else, please let us know.
Regarding the HTTP Request setup, it is important to note that there are many different ways to build custom solutions, and this is just one of them.
Each external application defines its own connection methods, documentation, and implementation rules. Unfortunately, we do not have access to every third-party application, nor do we have the expertise to map every possible use case across the countless tools available in the market.
For this reason, we are unable to provide active support for highly specific custom configurations. However, whenever the request involves Albato itself, our team is always happy to guide you as far as our scope of support allows, as we did in your case.
Overall, we sincerely appreciate the time you invested in sharing all of these valuable observations.
Our intention is not to justify any of the points you raised, but rather to provide broader context about Albato, how the platform operates, the scope of our support, and how all of these elements come together to help ensure a positive experience using our platform.
Our team is also continuously expanding our ecosystem of more than 1,000 available applications by adding new integrations, triggers, and actions. This helps further reduce the need for HTTP requests and other configurations that may require additional technical knowledge.
In addition, we will soon give AI Agents the ability to make custom HTTP requests and use Custom API Requests, making it much easier to create custom triggers and actions for applications that are not yet integrated with Albato.
Once this capability is available, Copilot will be able to build AI Agents that leverage these tools, providing users with a simpler way to create automations using these custom connections.
By the end of the year, we also plan to connect Copilot with App Integrator, streamlining and accelerating the entire process of building new app integrations across the platform.
Please be assured that our team will always be happy to help with anything within our scope, and we truly appreciate your trust in Albato.
Thank you again.