Canopy Connect | $160-205k | Full-time | Remote | US & Canada only | Product Engineer

Canopy Connect is single-click insurance data sharing (like "Plaid for insurance").

We serve over 3,500 companies (and growing rapidly!) including insurance agencies, lenders, insurtechs, fintechs, and insurance carriers to streamline acquiring verified insurance data from consumers and businesses.

We're hiring Product Engineers. We're a small, fully remote team based in the US and Canada. We present the best of both worlds - a nimble startup and small team (low strike price on equity and more ownership/impact), yet derisked because of our capital efficiency.

Apply here: https://www.usecanopy.com/company/careers

Do you hire only in the US and Canada?

Thanks for the question. Yes, we are only hiring in US and Canada.

Canopy Connect | Product Engineer | Full-time | Remote | https://www.usecanopy.com/company/careers

Canopy Connect is single-click insurance data sharing (like "Plaid for insurance"). We serve large and small insurance agencies, lenders, insurtechs, fintechs, and insurance carriers to streamline acquiring verified insurance data from consumers and businesses.

We're hiring Product Engineers. We're a small, fully remote team based in the US and Canada. Apply here: https://boards.greenhouse.io/canopyconnect

Hi friends! At Canopy Connect, We're building single-click insurance data sharing - think "Plaid for insurance". Our infrastructure powers best-in-class insurance experiences. We're hiring Senior Full-Stack Engineers, a VP of Operations, Director of Marketing and Recruiter/People Operations. We're a small, fully remote team based in the US and Canada. Check out our open roles here: https://boards.greenhouse.io/canopyconnect

So excited for this! Strong team and great product - I love using Remotion!

no the index update is asynchronous - it does not block the process at all.

Yes, see the github repo here: https://github.com/ttezel/unio

Yes my argument is simply that we publish API specs in a machine-readable format to avoid wasting time implementing clients repeatedly. WSDL and WADL had good intentions at heart, but XML is ugly. JSON is nice since it's human-readable and light. Why not publish JSON versions openly for REST APIs, reducing implementation cost for clients?

XML is human readable. It was meant to be (this is why it's text instead of some binary format). It's just really, really verbose, which is what this JSON spec is going to end up being once it's dealt with all imaginable edge cases.

> ... my argument is simply that we publish API specs in a machine-readable format

...

> ... XML is ugly. JSON is nice since it's human-readable and light.

???

Yes, there are some dots you need to connect between his two statements. I'm assuming that he meant the following: those machine-readable specs also need to be read by humans at some point, just like code, and, since JSON is more readable, he proposes using it instead of XML.

XML is more human readable than JSON, to my eyes.

That may be so, but most opinions I hear in discussions about XML vs JSON say that JSON is more readable, probably because it's less redundant and similar to data structures found in some programming languages.

Really? Let's write a shopping list on a piece of paper in JSON and XML. Which one would be more similar to the way we write down lists in real life?

XML:

   <list>
    <items> 
       <item>Milk</item>
       <item>Eggs</item>
       <item>Bread</item>
       <item>Butter</item>
     </items>
   </list>

JSON:

    {
       "list": {
         "items": [
            "Milk",
            "Eggs",
            "Bread",
            "Butter"
        ]
      }
    }

I don't know that either one is particularly close to the way I'd write down a list in real life, to be honest. This is a pretty trivial sample, and neither is especially hard to read/parse by a human. But the JSON still looks closer to line-noise to me. :-)

This seems similar in goal to the SPORE project (https://github.com/SPORE). Have you seen that and/or considered merging efforts?