Show HN: Sequin – Use Postgres/SQL to read from and write to APIs https://ift.tt/IqE1XJR

Show HN: Sequin – Use Postgres/SQL to read from and write to APIs Hi HN community, I'm Anthony, co-founder of Sequin (sequin.io), and am excited to show you what we've been working on. Sequin lets you skip HTTP APIs and integrate with Postgres and SQL instead. While we originally launched with a one-way sync from APIs to Postgres, as of today, you can now _write back_ to APIs using `insert`, `update`, and `delete` on your synced tables. We built Sequin because no one is happy with HTTP APIs today. For developers that need to build on top of third-party APIs, each integration is bespoke. There are few standards. I've personally seen over a dozen different OAuth 2.0 implementations, every JSON response format imaginably, and countless strategies for pagination. On top of that, poor throughput and/or rate limits mean every integration I've worked on has needed to cache or sync data. The platforms that provide HTTP APIs for consumers are equally unhappy. There are few standards that the industry adheres to, resulting in a process that is full of bike-shedding. And when it's finished, it's always disappointing, as even the best HTTP APIs are full of compromises and struggle to service the long-tail of use cases. This leads to frustration on both sides. At Sequin, we're building a platform that consists of two novel features that make both API consumers and providers much happier. The first is the feature we originally launched with: *we sync data from the API provider in real-time and put it in a Postgres database*. By extracting data out of the API and putting it in Postgres, consumers enjoy a number of benefits: 1. They can read their data without throughput limits, such as those imposed by rate limits. 2. They can query their data with all the expressiveness of SQL. SQL is an order of magnitude more expressive than the typical HTTP API. 3. They can use a standard interface they're familiar with (SQL) vs a bespoke one. In fact, they can just use their ORM to integrate, vs needing to use an under-supported API adapter library. We're launching our second innovation today: Developers can now write _back_ to the API via Sequin. *We intercept the mutations that you make to synced records in your database and apply them to the API as well*. In fact, our Postgres Proxy commits the write to the API _first_, before your database. This means that all the necessary policy that the API implements – like validation rules – are run against every database write. The API remains the source of truth, and the database never drifts. If the write fails API validation, the Proxy rolls the write back and returns a native Postgres error: ``` insert into salesforce.contact (first_name, last_name, email) values ('Andrea','Palladio','andrea__invalid') returning id; ERROR: [Salesforce]: Property values were not valid: `email` 'andrea_invalid' is invalid. ``` With these two components of our platform, APIs interfaces are no longer bespoke, they're familiar. We abstract away the common cruft of integrations, like syncing, cache invalidation, normalization, rate limit management, and token management. We let developers instead just focus on crafting the reads and writes that their application needs. You get to have the tables from the APIs across your stack right there in your database, fully readable and writeable. We only support three platforms today: Salesforce, HubSpot, and Airtable. We work hard to make the experience as seamless as possible, which takes a little time to build – but more platforms are on the way. One more thing: You don't need Postgres in your stack to use Sequin! We offer hosted databases that can serve as your API interface. Check out our docs to learn more. [0] Or, give it a spin for yourself. [1] If there's an integration you'd love to see supported or you have any questions/thoughts, let me know below! https://sequin.io [0] https://docs.sequin.io [1] https://app.sequin.io July 26, 2023 at 11:32PM