Ask HN: How does Merge.dev sell itself as a unified API?

2 points by thexumaker 1 year ago | 1 comment

Used Merge to hook up some HRIS and ATS systems at my old job and I'm genuinely not sure how they sell themselves as a unified API product

- Their entire scheme is just possibly undefined return values - Any custom data beyond just the basics are under a remote_data key that their docs don't even explain and just says "Varies by platform". Like at least tell us what each system could return cause otehrwise we have to manually QA every single HRIS/ATS anyways.

- The system doesn't even do any ETL. You still have to ETL and paginate through the system yourself. It's the lightest API wrapper ever that doesn't have a great schema.

- Their new SDK is much better generated but they didn't provide any legacy migration guides and their old sdks required us to fork their repo and build our own solution

- Honestly it seems like the only reason I've had to use Merge's API is because our CEO was friends with the Merge CEO

bastienbeurier 1 year ago |

If you are interested, we are working to solve these shortcomings at nango.dev.

Instead of having a black-box unified API, you can define the schemas/interactions between Nango & external APIs, in code. Which means you can do detailed data validation, specific to your use case, so you get back fully-typed objects. You control the data transformations to match your specific use case (so when APIs have different values for, let's say, "contact status", you define the mapping). You only sync the data you need, not full objects, so it's efficient.

A call to fetch records looks like this:

curl --request GET --url 'https://api.nango.dev/records?model=MODEL-DEFINE-BY-YOU' --header 'Connection-Id: YOUR-CUSTOMER' --header 'Provider-Config-Key: EXTERNAL-API'

Curious to hear what you think!