9 ms·

I've put a fair amount of work into getting this exact time as low as possible for my exchange rates API [1]. I've noticed slightly better conversion each time

by 256DEV 5y ago

I've put a fair amount of work into getting this exact time as low as possible for my exchange rates API [1]. I've noticed slightly better conversion each time I've taken a major step out of the process. I've specifically eliminated some of the steps this article cites in its example of a tedious flow - for instance I changed user accounts to be confirmed by default and then only disable them retroactively if a user doesn't click the activation link within 24 hours. This way you don't need to wait for the confirmation email. Even though I use Postmark delivery times can be surprisingly variable. I'm not sure how I could further improve the current flow, which is 1. put your email into the landing page, 2. then choose a password for your account, then 3. you're presented with an example request format including your already activated API key. Suggestions welcome! I guess because the scope of my service is so limited it's easy to have this fast flow, no complex libraries or auth is involved. 1. https://www.exchangerate-api.com https://www.exchangerate-api.com

Kiro 5y ago
> I'm not sure how I could further improve the current flow Remove 1 and 2.
- resonantjacket5 5y ago
  You need to assign the API key to an email both for contacting and also a way to limit abuse.
  - KeepFlying 5y ago
    But you could give a short lived highly limited API key out for testing to allow the potential user to test the API for their needs before bothering to make an account and providing their personal information.
    - mcint 5y ago
      Also, a way to register via that temporary api access
      - 256DEV 5y ago
        KeepFlying's idea together with this point is a great suggestion, I'm going to see if I can prototype something along these lines. Basically hand out tons of short lived credentials right from a widget on the main landing page, together with each API response giving a link to a signup form that can convert the key into a fully fledged account. Thanks for the suggestion!
    - stickfigure 5y ago
      How do you prevent someone from automating repeated "get new temp key"?
      - deleted 5y ago
        [deleted]
  - 256DEV 5y ago
    Abuse of free APIs is a big issue, I've definitely experienced it a lot and see other API developers in this thread mentioning it. With my experience though I found that trying to limit signups to prevent abuse caused so much friction for legitimate users that I actually decide to change my strategy to the following: 1. Allow essentially unrestricted access to the free account on a separate domain/hosting so that people don't feel the need to churn through accounts with bots etc. and the load can be separated out. Hence this page: https://www.exchangerate-api.com/docs/free https://www.exchangerate-api.com/docs/free My signup form actually automatically redirects some classes of disposable email, bot signup etc. to this page! 2. Make sure that anything particularly resource intensive or that's a good reason to sign up for my service is only accessible after payment. I would love to give out more functionality for free but unfortunately the people that take advantage mean it's just not economically possible. So for me the main reason to get an email address is 1.) so that users can have a better experience - get usage notifications, updates about the API that might affect them, share the account with a colleague etc. And 2.) so that business users can be satisfied. Pretty much anyone running a company that is relying on an API will want to have an account, see how the upgrade process would work if they needed it etc. even if they're only starting off with a free plan.
- 256DEV 5y ago
  So I actually do have a version of my API that doesn't require any sign up at all for the users that prefer this! You can see it here: https://www.exchangerate-api.com/docs/free https://www.exchangerate-api.com/docs/free That said, as much as some users want an open endpoint with zero authentication there are many others who want an actual account, commercial support, high availability, more features etc. These users are also the ones that pay for development, infrastructure etc. so my service has to be 95% built around the flow that includes signup.
  - StavrosK 5y ago
    Yes but you can let users sign up with their API token at any later time.
deleted 5y ago
[deleted]
stkdump 5y ago
For a more professional look, use higher res or vector graphics. Parts of the page (including the fixed header) look blurry, even on my phone with a relatively moderate by todays standards 1024px wide screen. I might be very particular about this, but I find it almost painful to look at the page for this reason.

by 256DEV 5y ago

Kiro 5y ago

> I'm not sure how I could further improve the current flow Remove 1 and 2.

resonantjacket5 5y ago
You need to assign the API key to an email both for contacting and also a way to limit abuse.
- KeepFlying 5y ago
  But you could give a short lived highly limited API key out for testing to allow the potential user to test the API for their needs before bothering to make an account and providing their personal information.
  - mcint 5y ago
    Also, a way to register via that temporary api access
    - 256DEV 5y ago
      KeepFlying's idea together with this point is a great suggestion, I'm going to see if I can prototype something along these lines. Basically hand out tons of short lived credentials right from a widget on the main landing page, together with each API response giving a link to a signup form that can convert the key into a fully fledged account. Thanks for the suggestion!
  - stickfigure 5y ago
    How do you prevent someone from automating repeated "get new temp key"?
    - deleted 5y ago
      [deleted]
- 256DEV 5y ago
  Abuse of free APIs is a big issue, I've definitely experienced it a lot and see other API developers in this thread mentioning it. With my experience though I found that trying to limit signups to prevent abuse caused so much friction for legitimate users that I actually decide to change my strategy to the following: 1. Allow essentially unrestricted access to the free account on a separate domain/hosting so that people don't feel the need to churn through accounts with bots etc. and the load can be separated out. Hence this page: https://www.exchangerate-api.com/docs/free https://www.exchangerate-api.com/docs/free My signup form actually automatically redirects some classes of disposable email, bot signup etc. to this page! 2. Make sure that anything particularly resource intensive or that's a good reason to sign up for my service is only accessible after payment. I would love to give out more functionality for free but unfortunately the people that take advantage mean it's just not economically possible. So for me the main reason to get an email address is 1.) so that users can have a better experience - get usage notifications, updates about the API that might affect them, share the account with a colleague etc. And 2.) so that business users can be satisfied. Pretty much anyone running a company that is relying on an API will want to have an account, see how the upgrade process would work if they needed it etc. even if they're only starting off with a free plan.
256DEV 5y ago
So I actually do have a version of my API that doesn't require any sign up at all for the users that prefer this! You can see it here: https://www.exchangerate-api.com/docs/free https://www.exchangerate-api.com/docs/free That said, as much as some users want an open endpoint with zero authentication there are many others who want an actual account, commercial support, high availability, more features etc. These users are also the ones that pay for development, infrastructure etc. so my service has to be 95% built around the flow that includes signup.
- StavrosK 5y ago
  Yes but you can let users sign up with their API token at any later time.

deleted 5y ago

[deleted]

stkdump 5y ago

For a more professional look, use higher res or vector graphics. Parts of the page (including the fixed header) look blurry, even on my phone with a relatively moderate by todays standards 1024px wide screen. I might be very particular about this, but I find it almost painful to look at the page for this reason.