TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Launch HN: API Tracker (YC W20) – Track and manage the APIs you use

125 pointsby cameroncooperover 5 years ago
Hey HN!<p>We’re Cameron, Trung and Matt from API Tracker (<a href="https:&#x2F;&#x2F;www.apitracker.com" rel="nofollow">https:&#x2F;&#x2F;www.apitracker.com</a>). We make tools to help with using third-party APIs in production.<p>When software teams integrate with APIs they often run into outages, network issues, interface changes or even bugs that cause unexpected behavior in the rest of their system. These problems are hard to predict and prepare for so most teams don’t deal with them until there&#x27;s a outage and have to do an emergency build to add logging and get to a root cause.<p>This is what happened to us. Trung and I are both software engineers and we spent a lot of time and energy trying to make our API integrations robust and reliable in production. We found ourselves instrumenting all our API calls so we could know how many calls we were making, how long they were taking and if they were failing. We set up alerts for errors and latency increases and integrated with PagerDuty. We wrote retry logic with exponential backoff. We wrote failover from one API provider to another. At the end of it all we built a lot of tooling that required maintenance and wasn’t even applied uniformly across all of our integrations.<p>After building all this infrastructure we realized that many other teams are reinventing the same wheel.<p>To solve this problem we built an API proxy that takes requests and relays them to the API provider. By proxying this traffic we are able to instrument each call to measure latency, record status codes, headers and bodies, and add reliability features like automatic retry with exponential backoff. From there we can monitor and alert on issues and provide a searchable call log for debugging and auditability.<p>We knew that because we were asking teams to run their mission critical API calls through us that we had to build a highly available and scalable proxy architecture. We’ve done this by designing a proxy that can be distributed across multiple regions and clouds. We are currently running out of AWS. Global Accelerator allows us to use their private internet backbone to quickly get traffic to our proxies which run behind AWS Network Load Balancers. While this can help us ensure resilience against infrastructure outages, we also need to protect against self-inflicted wounds like bugs and bad deployments. Upon release we bring up a new set of proxy instances, deploy the code, and run our full test suite to make sure that each instance is able to proxy requests correctly. Once all instances are healthy they begin to go into the load balancer.<p>For companies with more stringent needs we support on-premise installations as well as a client-side SDK that can do instrumentation without the proxy.<p>Today we offer the service as a subscription. We hope to make it easy for teams to get visibility and control across all their integrations without having to build it themselves. This includes:<p>- Detailed logging on all of their third-party API calls<p>- Monitoring and alerting for increased latency and error rates<p>- Reliability features like automatic retry, circuit breaker and request queueing<p>- Rate limit and quota monitoring<p>We would love to hear from the community how you are managing your API integrations. Our story is a result of our experiences and how we dealt with them, but we know the HN community has seen it all. We would love to hear from you about problems you’ve had and how you dealt with them. Please leave a comment or send us an email to founders@apitracker.com. Looking forward to the discussion!

16 comments

dolftaxover 5 years ago
We&#x27;ve been using API Tracker in production for few weeks now. The primary use case for us is to reliably handle webhooks from GitHub which our product relies heavily on (app installation, commit and pull request events).<p>Unfortunately, GitHub doesn&#x27;t retry any failed webhooks and when our service goes down for a few seconds, thousands of webhooks fail and pile up. GitHub doesn&#x27;t provide an API to query the failed webhooks and retry as well. We had to go through the painstaking task of visiting GitHub&#x27;s app dashboard and click retry on each webhook, one by one.<p>With API tracker in place, we&#x27;ve updated our GitHub app&#x27;s webhook delivery URL to send the webhooks to API tracker and they forward it to our services. In worst case when our service goes down for a while, API tracker gracefully retries all the failed webhooks.<p>Ref: <a href="https:&#x2F;&#x2F;github.community&#x2F;t5&#x2F;GitHub-API-Development-and&#x2F;Handling-GitHub-webhook-retry&#x2F;td-p&#x2F;25465" rel="nofollow">https:&#x2F;&#x2F;github.community&#x2F;t5&#x2F;GitHub-API-Development-and&#x2F;Handl...</a>
评论 #22359679 未加载
评论 #22360214 未加载
评论 #22360319 未加载
评论 #22366549 未加载
orliesaurusover 5 years ago
There have been a number of players in this area throughout the years (Galileo [RIP], Runscope [semi-RIP], Newrelic just to mention a few) for the analytical part ... and countless more for the proxying part (Kong, Envoy, Tyk, etc)<p>Can you elaborate a little bit more where you place yourself in the market? Why should someone trust you over any of the bigger, older and more stable competitors? Thanks
评论 #22358702 未加载
thdxrover 5 years ago
This is great, I can see the potential of something like this and am jealous I&#x27;m not the one working on it!<p>Don&#x27;t take the pushback in the other comments too seriously. There is definitely an audience (myself included) who&#x27;d want a focus, specific tool
评论 #22361849 未加载
incognosover 5 years ago
It is a nice solution but I am weary of anything that proxies my traffic. Especially considering the legislative environment. I&#x27;ve been using Bearer [<a href="https:&#x2F;&#x2F;www.bearer.sh" rel="nofollow">https:&#x2F;&#x2F;www.bearer.sh</a>] which does not use proxy but a library that hooks into the low level calls - It gives us a great view of what is going on with our third party API calls. You can filter out the calls that do not interest you and separate Production from Staging etc... I did not want to have to build the monitoring infra myself, not a core competency and for the money, it is cheaper to use an external service over 5 years vs. building in-house.
openthcover 5 years ago
We&#x27;ve had to build similar tools -- but one step further to make three different upstream services behave in a common way. We also added pre&amp;post flight error checking for cases where the backend wouldn&#x27;t behave nice.<p>Any plans to &quot;commonize&quot; some different-backends like Twilio &#x2F; Plivo, or SendGrid, Mandrill, etc, etc?<p>Very nice work!
评论 #22360143 未加载
time0utover 5 years ago
Congratulations on your launch! This is very interesting. I have a few questions. I apologize if your website answers these, but I couldn&#x27;t find clear answers after a cursory glance:<p>Can you tell me more about how the on-premise installation works and&#x2F;or is licensed?<p>Can it manage my authentication mechanisms for me? For example, can I configure it with my client side certificates or have it fetch and cache oauth tokens? We do this in our current solution and it is very nice being able to hide all these details from our applications.<p>Can it do request&#x2F;response transformation at all? We have a lot of cases where we want to massage things a little here and there. I realize this might be out of the scope of what you are trying to do, but it would be a nice to have.<p>We currently do this sort of stuff with a cluster of IBM Datapower gateways. They perform very well but are expensive, difficult to configure, and somewhat opaque.
评论 #22362044 未加载
mc3over 5 years ago
Hi I have two questions:<p>1. How can I be sure sensitive date sent via the APIs is secure &#x2F; private etc?<p>2. Is you reliability and availability 100%, because if I use you my app&#x27;s availability is now only as good as yours. We&#x27;ve been bitten by cascading effects of outages of upstream cloud services, but something like this would knockout everything I guess if it was down.
tonylucasover 5 years ago
Have just signed up, was (yet again) looking for a solution like this for monitoring outbound API calls. Look forward to trying it
sachinagover 5 years ago
<a href="https:&#x2F;&#x2F;cloud.ibm.com&#x2F;catalog&#x2F;services&#x2F;api-connect" rel="nofollow">https:&#x2F;&#x2F;cloud.ibm.com&#x2F;catalog&#x2F;services&#x2F;api-connect</a> seems to do a lot of this for free. Probably could also use the community version of Mulesoft: <a href="https:&#x2F;&#x2F;developer.mulesoft.com&#x2F;mulesoft-products-and-licensing" rel="nofollow">https:&#x2F;&#x2F;developer.mulesoft.com&#x2F;mulesoft-products-and-licensi...</a>
评论 #22360568 未加载
hn_throwaway_99over 5 years ago
Congrats on the launch. I have a ton of 3rd party APIs I&#x27;m integrating with, so like you have been thinking about all the stuff I&#x27;ll need to do to make it reliable in production.<p>What do you guys do for masking or encrypting sensitive data? I like the opportunity to log everything but a lot of what I&#x27;d want to log is PII or sensitive financial data.
评论 #22363204 未加载
FanaHOVAover 5 years ago
Started using apitracker a week or two ago; it&#x27;s been great for logging requests and inspecting failed&#x2F;slow ones. Haven&#x27;t tried automated retrying yet, but excited to do that soon as well.
评论 #22358917 未加载
jconleyover 5 years ago
Interesting service. Have built things like this a couple times. How is the on-premise version priced? Didn&#x27;t see that on the site anywhere.
评论 #22362307 未加载
datboitomover 5 years ago
Is this any different than Bearer.sh?
评论 #22361779 未加载
ignoramousover 5 years ago
Would it be right to say this is sentry.io meets envoy, grpc, and konghq? Super interesting. Congratulations.<p>How do I manage my API integrations, you ask?<p>Global Accelerator (GLA) is a key infrastructure piece for a HA service I&#x27;m building but for the data-plane. It is such a hassle-free but slightly expensive way to vend anycast IPs (no need to purchase ASNs and&#x2F;or announce routes from colos across the globe) and have the traffic load-balanced to 25+ AWS regions, that I recommend it instantly to anyone architecting HA services. <a href="https:&#x2F;&#x2F;fly.io" rel="nofollow">https:&#x2F;&#x2F;fly.io</a> and <a href="https:&#x2F;&#x2F;stackpath.com&#x2F;edge-computing" rel="nofollow">https:&#x2F;&#x2F;stackpath.com&#x2F;edge-computing</a> are viable alternatives. Cloudflare announced MagicTransit which isn&#x27;t as smooth as AWS GLA in terms of developer experience, whilst Azure and Google offer global-load-balancers, too, and may be even before AWS announced it in 2018? So, really, I think utilizing GLA is something folks should do if they run global HA services. The only issue with using NLB behind AWS GLA is the client-IP is not preserved. In our case, we needed it, so we had to get creative with sticky routing and port assignment (listeners) to do load-balancing &#x2F; traffic-shaping.<p>Another HA trick I plan to employ is to use Cloudflare-Workers (200+ PoPs) to front https-traffic to our control-plane endpoints. It lacks observability, monitoring, and alerting unless you&#x27;re on Cloudflare&#x27;s enterprise plans. The rate-limiting option is expensive ($0.05 per 10k good requests). I&#x27;m sure there&#x27;s no way to queue requests out-of-the-box, so I can very much see a need for what you&#x27;ve built, and where you guys fit in.<p>To be honest, I&#x27;d be surprised if firebase or API Gateway or KongHQ don&#x27;t already do what you do, as well. Is that case? If so, keep at it. It is a real need. And as you point out, something that I&#x27;ve <i>had to</i> build for every service and integration point.<p>A few questions (I went through your website and docs, but here I am):<p>- How do you handle secrets that the clients might need to share with your service, like Apikeys or Access&#x2F;SecretKeys?<p>- Do you also push logs to the customers in addition to them pulling it from your endpoints &#x2F; UI?<p>- A bit curious about your logging, monitoring, and alerting infrastructure-- Is it ran on top of CloudWatch or Prometheus or Loggly or Elasticsearch or Lightstep or...?<p>- Do you support proxying http&#x2F;REST APIs only?<p><a href="https:&#x2F;&#x2F;autocode.stdlib.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;autocode.stdlib.com&#x2F;</a> which was discussed a few weeks ago here looks, to me, like a good addition to what you&#x27;re building.
评论 #22360772 未加载
notlukeskyover 5 years ago
Is there an SLA roadmap?
derricgillingover 5 years ago
We at Moesif (<a href="https:&#x2F;&#x2F;www.moesif.com&#x2F;solutions&#x2F;track-third-party-api" rel="nofollow">https:&#x2F;&#x2F;www.moesif.com&#x2F;solutions&#x2F;track-third-party-api</a>) released a similar tool in 2017 and found that many of our customers including Deloitte, UPS, Snap Kitchen, iFit, and Trung&#x27;s previous company, Snap Kitchen were looking for a way to track APIs without the complexity of a full service mesh like Envoy. Especially if you&#x27;re hosted in something that cannot run an on-prem service mesh or gateway.<p>We&#x27;re a little different in that we also support agent-based rather than just proxy. Meaning we have an SDK that sits out-of-band.