4 ms·

It always boggles my mind when I try to use a new API and I have to jump through a hundred hurdles to start using it. Let me use your service and start paying

It always boggles my mind when I try to use a new API and I have to jump through a hundred hurdles to start using it. Let me use your service and start paying you! In the ocean of bad APIs out there I'll pick yours if you can offer: 1. An easy process to onboard 2. Good documentation 3. Usage based pricing

dexterdog 5y ago
If you have some kind of pricing model I understand the basic email validation and possibly getting a payment method up-front. It's too easy to program around a simple usage cap.
- matsemann 5y ago
  Having a fake/temporary/nonpersistent/whatever-makes-sense instance one can quickly test in swagger or similar tools just to get a feel would be nice, though.
dna_polymerase 5y ago
Maybe we should collect some good and bad examples here. Personally I dislike the onboarding situation at Twilio, their documentation is good though. Mailjet has good documentation and decent onboarding.
- sdenton4 5y ago
  I spent a good hour just getting the Box cli running yesterday... Which requires a developer account, creating a 'custom app' to facilitate the CLI interactions, going into an obscure admin interface to approve the request to make the custom app, generating a key pair and downloading configurations for the app, downloading npm crud, and sharing data with the service account associated with the custom app, using uids that aren't terribly obvious in the user facing world. But then it works just fine! :P
Silhouette 5y ago
I would add: 4. A meaningful indication of API stability and planned longevity 5. A viable method to run automatic integration testing during development I want an honest answer to how often you're expecting to break my integration and cause me extra work, and if you do that, I want to be confident that I've done enough to update my integration so it still works without having to manually retest the entire thing.
1123581321 5y ago
Agreed with the first two. I’m happy with a different pricing model so long as it’s financially viable at our usage tier and self-serve. On a project with a budget, or with funding, there isn’t a meaningful difference between a free trial, prorated per call, and paying for a month upfront.
- gowld 5y ago
  Those are all "usage" based if you aren't nitpicking. The major alternative is app store (and some SDKs) style of revenue-bases pricing
  - 1123581321 5y ago
    Fair. Revenue-based is indeed frustrating if it inhibits self-serve; otherwise, I’ve no issue with it.

dexterdog 5y ago

If you have some kind of pricing model I understand the basic email validation and possibly getting a payment method up-front. It's too easy to program around a simple usage cap.

matsemann 5y ago
Having a fake/temporary/nonpersistent/whatever-makes-sense instance one can quickly test in swagger or similar tools just to get a feel would be nice, though.

dna_polymerase 5y ago

Maybe we should collect some good and bad examples here. Personally I dislike the onboarding situation at Twilio, their documentation is good though. Mailjet has good documentation and decent onboarding.

sdenton4 5y ago
I spent a good hour just getting the Box cli running yesterday... Which requires a developer account, creating a 'custom app' to facilitate the CLI interactions, going into an obscure admin interface to approve the request to make the custom app, generating a key pair and downloading configurations for the app, downloading npm crud, and sharing data with the service account associated with the custom app, using uids that aren't terribly obvious in the user facing world. But then it works just fine! :P

Silhouette 5y ago

I would add: 4. A meaningful indication of API stability and planned longevity 5. A viable method to run automatic integration testing during development I want an honest answer to how often you're expecting to break my integration and cause me extra work, and if you do that, I want to be confident that I've done enough to update my integration so it still works without having to manually retest the entire thing.

1123581321 5y ago

Agreed with the first two. I’m happy with a different pricing model so long as it’s financially viable at our usage tier and self-serve. On a project with a budget, or with funding, there isn’t a meaningful difference between a free trial, prorated per call, and paying for a month upfront.

gowld 5y ago
Those are all "usage" based if you aren't nitpicking. The major alternative is app store (and some SDKs) style of revenue-bases pricing
- 1123581321 5y ago
  Fair. Revenue-based is indeed frustrating if it inhibits self-serve; otherwise, I’ve no issue with it.