Company

Language:

Pulling back the curtain on doola’s Company Formation API

By Lee Hambley

Published on 17 Nov 2022 3 min read

Learn how our Company Formation API can give your community access to launch LLCs, C Corps, and DAO LLCs easily, from the command line.

In this post, we want to offer a peek into the design and thought process behind the first part of our ubiquitous API concept, which we will be expanding on over the coming weeks and months!

Why we built an API

As a heavily user-focused company, forming partnerships with entrepreneurs at the start of their journey, we owe a lot of our success to the success of our customers. We are in the purest sense, a customer-driven company.

A strong API focus in a customer-success-focused domain is a commitment for us. At doola, we want to put into the hands of our customers and partners the same tools that we have at our disposal.

Building an easy-to-use API

We’re making some bold technical choices at doola in order to meet our customers and partners on their own terms, preferring technologies that speak their language rather than expecting those people working with our APIs to adapt to our vocabulary and domain. We’re reaching for web and industry standards such that experts in company formation, tax & compliance, banking, and other verticals will find a familiar and effective API when they work with our tools.

GraphQL is one of our key enablers in this domain, originally from Facebook circa 2015, GraphQL was originally designed to help mobile clients make fast queries against such features as the Facebook timeline by querying only the data it needed at any time.

GraphQL has, in the meantime, vastly grown in popularity (and divisiveness) as it became renowned for excellent documentation capability, use-case flexibility, and a “remote procedure call” style of use.

Typically (web) APIs are written in the REST-like (REpresentational State Transfer) style, REST is a pattern developed by internet pioneer Roy Fielding in the early 2000s in his Ph.D. thesis and essentially “extends” the web layer with application semantics.

REST, HATEOAS, and RDF all belong to a category of technology that almost had their golden age but never quite delivered on the promise of universally interoperable systems based solely on agreed data interchange and RPC standards.

In a REST-style API, a formation API would be modeled as a “PUT /companies” with a data payload containing probably some “form-data” or, in the current technological climate, more likely a JSON document. For a simple case like formation, this is fine, but the metaphor can soon break down, cancelling a formation of a company, for example, in HTTP+REST sense, might be modeled as the use of the “DELETE” verb against the same endpoint, or a “PATCH /companies/:id with a payload like {isCanceled: true},” suddenly we’re not speaking the same language as our business stakeholding peers.

The “POST /graphql” and “mutation” parts are unavoidable “noise” in the API, but thanks to the power of GraphQL, the “params” sent can be type-checked and validated by the client, and the interactive browse-able documentation can be used with autocompletion to make working with our API in an IDE (integrated development environment) easier. After sending the request, the client knows immediately, in the above example, if it was a success or not, and in case it was a success, they can select the company attributes immediately. “Companies” in the API clearly have lots more attributes, and thanks once more to the reference docs, individuals, customers, our partners, and ourselves can build both low and high-fidelity interfaces on top of automation, user interfaces, or any use-case.

GraphQL is the technology that allows us to adapt our technology to the solutions in the real world in a familiar way, in GraphQL this these kinds of use cases are natural:

Without a forced pseudo-hierarchical nature of the REST-like API, and the forced mapping of user intent into one of the five REST verbs (“GET” , “PUT” , “PATCH” , “POST” , “DELETE“), we open up a lot more freedom to capture the use cases from the perspective of various actors and entities in the complicated world of formation, and operating a business.

The future is doola API

We’re doing a lot of interesting things in our API, and GraphQL is an enabler for us to continue to innovate. We’ll be writing more and more about our API, for example, about our decentralized authentication and authorization service design, our data model design, and indeed also our relationship with AWS AppSync, and how this is an enabler for multi-functional engineering teams to maintain velocity in a polyglot technical environment.

The Company Formation API and the supporting boilerplate are just the first places we’re choosing to go!