I have made the bugs less prominent in the support forum. I am for full transparency, but in contrast to other systems, where the bug reports are very often confidential or handled via Chat am PM, they are very prominent in the support forum and I don’t want to give users the appearance that it is all about bugs here.
I just published a new blog post post. Read more at: https://squidex.io/post/upcoming-change-to-our-pricing-model
Thanks for the blog post. I do recognize why you’ll change the pricing structure.
Since you lowered the threshold for the free tier, I suggest a compromise: If a user adds payment options to a free plan, he’ll be charged for API calls 20001 through 30000 where the block limit for the free plan could be set. This would not completely block the free tier after 20000 calls but you can charge extra if the user wants you to. What are your thoughts?
Yes, makes sense, I will see if I can implement that.
I have promised to implement a better notification when you are about to reach you api limits and this has been deployed. The new system makes a forecast:
e.g.
var estimatedUsages = (callsThisMonth / dayInMonth) * numberOfDaysThisMonth;
You will be notified when you are about to reach the included limit, NOT the blocking limit.
I just published a new blog post post. Read more at: https://squidex.io/post/first-feature-udpate-2020
I just published a new blog post post. Read more at: https://squidex.io/post/new-feature-content-embedding
I just published a new version with an improvement to the asset endpoint. You can add the query-string “auto=true” now to let the API decide which format to return.
Right now it only works for webp, because the avif encoder is too slow.
I just published a new blog post post. Read more at: https://squidex.io/post/squidex-7.0-release-candidate-3-released
I just published a new blog post post. Read more at: https://squidex.io/post/squidex-7.1-released-graphql-subscriptions-and-translation-status