Nadles vs Zuplo

Comparison of monetization capabilities.

← Back to main page

	Nadles	Zuplo
Payment integrations	Stripe, Paddle	Stripe
Merchant of Record option	Yes You can use Paddle for payment processing and global tax compliance. Nadles augments Paddle with usage-based pricing models.	No Stripe only.
Billing cycle How often you can charge your customers	Any You can bill your customers on an arbitrary schedule. Example: you can bill a $20 monthly fee and charge for metered usage every week in the same subscription, in order to reduce credit risk.	Monthly Zuplo only supports monthly Stripe subscriptions.
Billable metrics What you can charge for	Anything API calls, sent SMS, processed images, ChatGPT tokens, credits, etc.	Anything
Usage metering conditions	Any arbitrary condition You can flexibly configure, in what cases Nadles should record usage. The usage condition can be based on any request and response attributes.	Response status codes only You can configure the response codes for which Zuplo will record usage.
Custom terms per customer	Yes You can fully customize product terms for individual customers.	No
Configurable spend limits Protect your customers from overages. Why is this useful?	Yes	No
Adjustable purchase quantity Let customers configure their subscriptions. Why is this useful?	Yes	No
Product templates Use pre-defined templates to create your API products in seconds. Customize them as needed.	Yes	No
Limited seats Limit maximum number of subscriptions to a product. Why is this useful?	Yes	No
Product-scoped request and response transformations Why is this useful?	Yes Use JavaScript or jq to write complex transformations.	No
Meter once Record usage only once for API calls with the same parameters. Why is this useful?	Yes	No
Product-scoped access rules You can decide which endpoints to include in the product.	Yes	Yes
Product-scoped rejection rules Make API gateway drop certain requests based on request attributes. Why is this useful?	Yes	No
No-code	Yes You can start selling your API with several mouse clicks.	No Zuplo is a programmable API gateway, meaning, you have to write code.
Vendor lock-in	Minimized Nadles tries to be present in your life and in the lives of your customers as little as possible. It only takes care of billing and subscription-related matters, leaving the most of developer experience in your hands.	It depends Zuplo offers all-in-one solution for API management, including developer portals, documentation, etc. When migrating away, you can take all the logic you've programmed for Zuplo with you. If your own API gateway is also written in TypeScript.
Best for	Small and medium-sized enterprises and individual entrepreneurs valuing their time	Developers loving to code and experiment with technology

Start your free trial today

Try Nadles for 14 days. No credit card required.

Free trial for 14 days →

© Leotech s.r.o., 2022-2024. All Rights Reserved.

Status

|

This feature allows you to modify requests and responses if the current user is subscribed to a certain product.

Use case examples:

Return full article text for users subscribed to Premium and truncate it for users subscribed to Basic product.
Enforce a maximum of 10 elements per page by replacing the perPage query string parameter to always be 10.
Configure your API on the fly:
Add header X-Job-Timeout: 10s to each request for Basic product,
X-Job-Timeout: 600s to each request for Premium product and use these values in your API to set different timeouts for users with basic and premium subscriptions.
Implement feature toggles:
Add header X-Enabled-Features: to each request, check it on the API side and enable or disable features for the current user accordingly.

Say, you have two endpoints:

Run a job
Retrieve the results

And you want to charge your customers only for the first time they retrieve the results, as the subsequent calls will be served from cache.

Using "meter once" feature, you can make Nadles do exactly that: record metered usage only for the first call to the result retrieval endpoint.

You might want to run a promo campaign with a limited number of seats available.

Limited offer! $20 per month instead of $99. 100 seats available.

Using Nadles checkout links, you can limit the maximum number of subscriptions made via that link, which makes it trivial to run promo campaigns like that.

Spend limits allow you to protect your customers from accidentally overusing your API.

A mistake in the application code or a malicious user trying to abuse the app can cause hundreds of thousands of unexpected API calls resulting in a huge bill for the customer.

With spend limits, customers still pay for what they actually use and can set the maximum usage limit to protect themselves from huge bills — the API gateway won't let them make more calls than configured.

You can configure the spend limit for each product and each customer individually.

You can also allow your customers to adjust the maximum usage limit on their own during the checkout.

You can let your customers change the included volume of API calls (or other billable metrics) when they make a purchase.

This allows them to pick the most comfortable terms, get volume discounts if you offer tiered pricing (the bigger the purchase volume, the lower the price per unit) and have more control over their costs.

Rejection rules allow you to model your API products more precisely by dropping certain requests based on request attributes.

Use case examples:

Allow USD to EUR currency conversion only.

Reject request if query string param "from" is not USD or "to" is not EUR.
Allow maximum of 10 elements submitted via a batch endpoint.

Reject request if JSON request body field "items" is longer than 10 elements.
Allow maximum of 1000 characters in a request to a Text-to-Speech engine.

Reject request if query string param "query" is longer than 1000 characters.